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Support  for  Temporal  Events  in  Sentinel: 
Design,  Implementation,  and  Preprocessing* 


ABSTRACT 


During  the  last  decade,  the  functionality  of  databases  has  been  extended  to  encompass  a  large 
range  of  applications  which  tend  to  be  very  complex  in  nature  with  concomitant  increase  in  database 
size  requirements.  Database  management  systems  (DBMSs)  have  evolved  to  meet  the  requirements 
of  emerging  applications.  Providing  monitoring  and  reactive  capabilities  to  existing  conventional 
DBMSs  without  application  or  user  intervention  is  one  of  the  directions  taken  to  deal  with  non- 
traditional  real  world  applications.  In  contrast  to  a  conventional  DBMS  which  is  considered  as 
passive  or  non-active,  the  self-reacting  DBMS  is  termed  active.  The  active  DBMS  typically  accepts 
EGA  (event-condition-action)  rules  which  specify  situations  that  need  to  be  monitored  and  reacts 
to  those  situation  under  certain  conditions.  An  active  DBMS  adds  three  new  features  to  a  passive 
DBMS:  i)  Rule  Interface  to  define  EGA  rules,  ii)  Event  detect  mechanism  to  detect  the  events 
specified  through  the  rule  interface,  and  iii)  Action  execution  mechanism  to  execute  the  action  of 
the  rule  whose  condition  evaluates  to  true  when  the  event  occurs. 

This  work  extends  Sentinel  by  completing  the  local  event  detector  to  support  temporal  events, 
and  by  pre-processing  the  Snoop  event /rule  specification  language  to  generate  appropriate  calls  to 
the  event  detector.  A  few  Snoop  operators,  such  as  A,  A*,  P  and  P*,  are  implemented  as  part  oi  this 
effort  to  handle  the  temporal  events.  This  work  first  describes  how  the  local  event  detector  works 
(e.g.,  construction  of  event  graph  and  event  notification  mechanism)  followed  by  the  description  of 
the  temporal  event  handler  and  its  integration  into  the  event  detector.  We  also  describe  the  Snoop 
preprocessor  and  its  integration  into  the  preprocessor  of  Open  OODB  (from  Texas  Instruments, 
Dallas),  which  is  used  as  the  underlying  platform  for  Sentinel. 

*This  work  was  supported  by  the  Office  of  Naval  Research  and  the  Naval  Command,  Control  and  Ocean  Surveil¬ 
lance  Center  RDT&E  Division,  and  by  the  Rome  Laboratories  under  contract  No.  F30602-95-1-0030 
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1  Introduction 


Conventional  database  management  systems  (DBMS)  perform  updates  and  execute  queries  in  a 
demand-based  manner,  either  when  applications  programs  are  executed  or  when  interactive  users 
perform  some  operation.  A  demand-based  approach  is  inadequate  for  meeting  the  requirements  of 
newer  applications  with  a  clear  need  for  monitoring  and  reacting  to  pre-defined  situations  automati¬ 
cally  without, any  user /application  intervention.  As  an  example,  consider  a  process  control  environ¬ 
ment  where  there  is  a  need  to  continuously  monitor  the  valve  pressures  to  ensure  that  the  pressure 
does  not  exceed  a  particular  threshold.  In  such  situations,  it  is  desirable  to  remove  the  human  from 
its  loop,  as  a  hur^an  cannot  always  ensiure  timely  response  to  critical  situations,  e.g.,  very  high 
pressures  in  the  valves.  DBMSs  with  the  added  functionality  of  asynchronously  monitoring  situa¬ 
tions  and  reacting  to  these  situations  are  called  active  DBMSs  (ADBMS).  In  contrast,  conventional 
DBMSs  are  referred  to  as  passive  [Cha90].  ADBMSs  typically  use  EGA  (event-condition-action) 
rules  to  specify  situations  to  be  monitored  and  how  to  react  to  these  situations.  Briefly,  an  event  is 
an  indicator  of  a  happening  which  can  be  simple  or  complex,  a  condition  is  a  query  based  on  either 
the  existing  database  state,  a  set  of  objects,  or  transition  between  states  of  objects  or  even  trends 
and  historical  data,  and  lastly,  actions  specify  the  operations  to  be  performed  when  an  event  has 
occurred  and  the  condition  evaluates  to  true.  ADBMS  adds  three  new  featmres  to  a  DBMS: 

•  Rule  Interface:  This  allows  applications  to  deflne  EGA  rules. 

•  Event  Detector:  This  is  the  entity  which  monitors  applications  as  well  as  the  database  to 
detect  the  occurrence  of  primitive  events.  It  is  important  to  note,  that  once  primitive  events 
aie  detected,  it  is  possible  to  group  these  primitive  events  to  detect  complex/composite  events. 

•  Action  Execution;  This  module  is  responsible  for  scheduling  and  managing  the  execution  of 
rule  actions  in  accordance  with  EGA  rule  execution  semantics. 

Figure  1  demonstrates  the  major  functional  extensions  an  ADBMS  provides  to  conventional  passive 
DBMS  to  support  active  capability  at  the  application  level. 

Most  of  the  earlier  work  on  ADBMS  has  concentrated  on ‘the  support  of  active  capability  in 
the  context  of  relational  database  systems.  Recently,  there  have  been  a  number  of  attempts  at 
incorporating  EGA  support  into  an  object-oriented  database  management  system  (OODBMS). 
Sentinel  is  an  ADBMS  based  on  OODBMS.  Sentinel  uses  Snoop  [Mis91,  GM94a]  as  its  event/rule 
specification  language  and  provides  various  parameter  or  event-consumption  contexts  for  detecting 
composite  events  to  meet  a  wide  range  of  real-world  application  needs. 

This  work  extends  the  earlier  work  on  Sentinel  [Mis91,  GM94a,  Kri94]  by  adding  the  followings: 
i)  the  stand-alone  temporal  event  detector  is  integrated  into  the  Sentinel  local  event  detector,  ii) 
implementation  of  relative  temporal  event,  iii)  implementation  of  several  Snoop  operators  (A,  A*, 
P  and  P*),  and  iv)  a  pre-processor  for  detecting  Snoop  event  expressions  and  processing  them 
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Applications 


Figure  1:  Major  Extensions  of  a  Regular  DBMS  to  an  ADBMS 


appropriately.  This  report  also  describes  the  data  structures  and  implementation  details  of  the 
event  detector. 

The  remainder  of  this  report  is  structured  as  follows.  Section  2  briefly  describes  the  related 
work  on  active  DBMSs.  Section  3  summarizes  Snoop,  and  Section  4  describes  the  architecture 
of  Sentinel.  Section  5  describes  how  the  event  detector  works,  and  Section  6  discusses  the  Snoop 
preprocessor.  Section  7  has  conclusions  and  future  work. 
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2  Related  Work 


In  this  Section,  a  few  active  OODBMSs  axe  examined  to  indicate  how  they  provide  the  active 
behavior. 

2.1  Ode 

Ode  [GJS92b,  GJS92a]  is  a  database  system  which  is  based  on  the  object-oriented  paradigm.  The 
database  is  defined,  queried  and  manipulated  using  the  database  programming  language  0-1— t-, 
which  is  an  upward-compatible  extension  of  the  object-oriented  programming  language  C-b- 1-.  Ac¬ 
tive  behavior  in  Ode  is  provided  by  incorporating  constraints  and  triggers  [GJ91]  without  the  notion 
of  EGA  rules.  Both  constraints  and  triggers  consist  of  a  condition  and  an  action.  Constraints  and 
triggers  are  defined  declaratively  within  a  class  definition.  Constraints  are  used  to  maintain  object 
consistency  which  are  applicable  to  all  instances  of  a  class  as  well  as  its  subclasses.  Triggers,  on  the 
other  hand,  axe  used  for  purposes  other  than  object  consistency  and  are  applicable  only  to  those 
instances  of  the  class  in  which  they  axe  declared  (along  with  its  subclasses),  specified  explicitly  by 
the  user  [GJ91].  A  trigger  is  activated  on  an  object  by  an  explicit  invocation.  A  condition  Ci  is 
paired  with  an  action  Ai  only,  forming  a  constraint  or  trigger.  Constraints  and  triggers  axe  fired  as 
a  result  of  the  invocation  of  any  non-constant  member  function.  Thus  events  in  Ode  are  considered 
as  the  disjunction  of  all  non-constant  member  functions.  Events  are  generated  as  a  result  of  the 
invocation  of  non-constant  public  member  functions.  Private  and  protected  member  functions  do 
not  generate  events.  All  events  signaled  by  an  object  of  class  A  cause  the  evaluation  of  all  con¬ 
straints  and  triggers  declared  within  class  A.  That  is,  event  detection  occurs  via  a  method  based 
mechanism:  constraints  and  triggers  axe  precompiled  into  each  place  in  the  code  where  they  might 
be  activated,  specifically,  at  the  end  of  each  non-constant  public  member  function  and  before  the 
commit  of  every  transaction. 

Ode  [GJS92b,  GJS92a]  has  also  proposed  a  language  for  specifying  composite  events.  Basic 
(primitive)  events  axe  defined  and  composite  events  axe  constructed  by  applying  operators  to  basic 
events.  The  basic  events  that  are  supported  axe  object  state  events  (creation,  deletion,  access, 
update,  read),  method  execution  events  (before  or  after  the  execution  of  a  method),  timed  events 
and  transaction  events.  The  event  operators  supported  axe  relative,  prior,  sequence,  choose,  every, 
fa  and  faAbs.  Basic  events  can  be  qualified  with  a  mask,  thus  producing  logical  events.  A  mask  is 
an  optional  predicate  that  allows  users  to  specify  more  complex  events.  For  instance,  assume  that 
the  execution  of  the  withdraw  method  constitutes  a  basic  event. 

Detection  of  composite  events  is  accomplished  by  using  finite  automata.  Each  event  expression 
maps  an  event  history  to  another  event  history  that  contains  only  the  events  at  which  the  event 
expression  is  satisfied  and  the  trigger  should  fire  [GJS92b,  GJS92a].  Each  event  expression  has  an 
automaton  associated  with  it  that  reaches  the  acceptance  state  when  the  event  is  raised.  Input 
to  the  automaton  is  the  event  history,  the  sequence  of  logical  events,  of  the  object  with  which  the 
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automaton  is  associated. 

Events  in  Ode  are  treated  as  expressions  declared  within  class  definitions  at  compile  time.  This 
approach  has  several  disadvantages.  First,  the  treatment  of  events  as  expressions  results  in  a  di¬ 
chotomy  between  events  and  other  objects.  Second,  events  cannot  be  created,  deleted  and  modified 
dynamically.  In  addition,  the  introduction  of  new  event  types,  attributes  and  operations  requires 
major  modifications,  thus  compromising  the  system’s  extensibility.  The  major  disadvantage  of  this 
approach  is  its  inability  to  express  complex  events  that  are  raised  by  occurrences  of  events  in  dif¬ 
ferent  classes.  To  clarify.  Ode  has  adopted  a  local  view  of  complex  events;  a  complex  event  defined 
in  class  A  can  only  be  raised  by  events  occurring  in  that  same  class  A. 

Ode  supports 'two  coupling  modes\  immediate  and  deferred. 


2.2  ADAM 

ADAM  [DPG91]  is  an  active  OODB  implemented  in  PROLOG.  It  treats  the  rules  uniformly  as  other 
objects,  and  rule  operations  are  implemented  as  class  methods.  Rules  are  incorporated  in  ADAM 
by  using  an  object-based  mechanism.  Basically,  an  object’s  definition  is  enlarged  to  indicate  which 
rules  to  check  when  the  object  raises  an  event.  Inheritance  of  rules  from  superclasses  to  subclasses 
is  supported.  However,  the  method  by  which  inheritance  is  supported  is  specific  to  the  PROLOG 
language  and  hence  cannot  be  easily  applied  to  other  object-oriented  programming  languages. 
ADAM  does  not  efficiently  allow  a  rule  to  be  applicable  to  only  one  instance  of  a  class.  This  is 
accomplished  by  disabling  the  rule  for  all  other  instances.  ADAM  allows  a  rule’s  constituents  to  be 
modified  dynamically.  For  example,  it  is  possible  to  specify  the  condition  and  action  parts  of  the 
rule  at  run  time.  Furthermore,  the  condition  and  action  parts  are  defined  dynamically  rather  than 
at  compile  time.  The  dynamic  characteristics  provided  by  ADAM  are  influenced  by  the  interpretive 
environment  in  which  ADAM  is  implemented  and  thus  it  is  difficult  to  accomplish  all  of  this  in  a 
language  such  as  C+-t-. 

Unhke  Ode,  ADAM  adopts  the  EGA  rule  format.  Events  in  ADAM  axe  also  treated  as  objects 
which  are  created,  modified  and  deleted  in  the  same  fashion  as  other  objects.  An  event-class 
is  defined  having  three  subclasses:  db-eveni^  dock-event  and  application-event.  Each  event  is  an 
instance  of  one  of  these  three  subclasses.  Events  in  ADAM  are  basically  generated  either  before  or 
after  the  execution  of  a  method.  When  an  event  is  raised,  all  the  methods’  arguments  are  passed  by 
the  system  to  the  condition  and  action  part  of  the  rule.  Thus,  the  condition  and  action  code  may 

^The  coupling  mode  denotes  when  the  condition  is  to  be  evaluated  with  respect  to  the  triggering  transaction. 
HiPAC  [Cha89,  DBM88]  introduces  three  coupling  modes,  namely,  immediate,  deferred  and  detached.  The  immediate 
coupling  mode  specifies  that  a  condition  is  to  be  evaluated  immediately  after  the  signaling  of  the  triggering  event. 
This  mode  causes  the  temporary  suspension  of  the  triggering  transaction  until  the  condition  is  evaluated.  The  second 
coupling  mode;  deferred,  causes  the  condition  to  be  evaluated  at  the  end  (before  the  commit)  of  the  triggering 
transaction.  The  last  coupling  mode,  detached,  causes  the  condition  to  be  evaluated  in  a  separate  transaction.  This 
mode  has  two  variations,  specifically,  causally  dependent  and  causally  independent.  Causally  dependent  coupling 
mode  implies  a  commit  dependency  between  the  triggering  transaction  and  the  rule,  whereas  causally  independent 
implies  that  the  rule  is  executed  as  a  separate  transaction  independently  of  the  triggering  transaction. 
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refer  to  the  method’s  input  or  output  parameters  during  evaluation.  In  order  to  create  an  event, 
the  user  must  specify  the  name  of  the  method  generating  the  event  and  when  the  event  should 
be  raised.  Although  ADAM  does  not  support  complex  events,  the  system  is  extensible  enough  to 
support  them.  This  is  due  to  their  treatment  of  events  as  objects. 

ADAM  only  supports  the  immediate  coupling  mode  and  does  not  support  the  other  coupling 
modes  proposed  in  HiPAC  [Cha89,  DBM88]. 

2.3  Sentinel 

Sentinel  is  an  integrated  active  DBMS  incorporating  EGA  rules  using  the  Open  OODB  Toolkit 
(from  Texas  Instruments,  Dallas).  Event  and  rule  specifications  are  seamlessly  incorporated  into 
the  C++  language.  Any  method  of  an  object  class  is  a  potential  primitive  event.  Furthermore, 
before-  and  a/ter- variants  of  method  invocation  are  allowed  as  events.  Composite  events  are  formed 
by  applying  a  set  of  operators  to  primitive  events  and  composite  events.  Events  and  rules  are 
specified  in  a  class  definition.  In  addition.  Sentinel  supports  events  and  rules  which  are  applicable 
to  a  specific  object  instance.  In  that  case,  events  and  rules  axe  specified  outside  of  class  definitions 
within  the  program  where  instance  variables  are  declared.  Supporting  this  instance-level  events 
and  rules  removes  the  significant  drawback  of  ADAM’s  local  view  of  composite  events  and  allows 
composite  events  which  are  combinations  of  events  firom  different  classes  or  different  applications 
(global  events). 

The  parameters  of  a  primitive  event  correspond  to  the  parameters  of  the  method  declared  as  the 
primitive  event  and  Other  attributes,  such  as  the  time  of  occurrence.  The  processing  of  a  composite 
event  entails  not  only  its  detection,  but  also  the  computation  of  the  parameters  associated  with  a 
composite  event.  The  parameters  of  a  composite  event  are  collected,  recorded  and  passed  on  to 
condition  and  action  portions  of  a  rule.  Furthermore,  these  parameters  are  stored  and  reordered 
to  meet  various  parameter  contexts  which  are  used  to  capture  the  application  semantics.  Recent, 
Chronicle,  Continuous,  and  Cumulative  parameter  contexts  are  supported  in  Sentinel. 

An  event  (primitive  as  well  as  composite)  can  trigger  several  rules,  and  rule  actions  may  raise 
events  which  can  trigger  other  rules.  Sentinel  supports  multiple  rule  executions,  nested  rule  ex¬ 
ecutions  as  well  as  prioritized  rule  executions.  The  three  coupling  modes  (immediate,  deferred 
and  detached)  discussed  in  HiPAC  [Cha89,  DBM88]  were  introduced  to  support  application  needs. 
Currently  immediate  and  deferred  modes  have  been  implemented  in  Sentinel. 


5 


3  Summary  of  Snoop 

This  section  provides  an  overview  ^  of  the  event  specification  language  Snoop  used  in  Sentinel  for 
specifying  EGA  rules.  Snoop  uses  an  even  hierarchy  to  classify  events,  defines  the  notion  of  events 
and  event  expressions,  and  describes  a  set  of  event  operators  ^  for  constructing  composite  events. 

3.1  Event,  Event  Expression,  and  Condition 

An  event  is  an  atomic  (happens  completely  or  not  at  all)  occurrence,  and  an  event  expression 
is  an  expression  which  defines  an  interval  on  the  time  line.  A  database  transaction,  operation, 
or  a  function  can,  be  regarded  as  an  event  expression  since  typically  it  takes  a  finite  amount  of 
time  for  its  execution.  Since  an  absolute  point  on  the  time  line  (which  is  corresponding  to  an 
absolute  time)  can  be  viewed  as  a  degenerate  event  expression  where  a  point  is  a  special  case  of  an 
interval,  choosing  a  point  that  can  be  declared  as  an  event  corresponding  to  that  event  expression 
is  necessary.  Event  modifiers  [CM94b]  are  used  to  transform  an  event  expression  to  one  or  more 
events  which  correspond  to  various  points  of  interest  on  the  time  line  for  that  event  expression. 
Snoop  provides  two  event  modifiers,  hegin-of  and  end-of  to  transform  an  arbitrary  interval  on  the 
time  line  into  an  event. 

A  condition  is  a  boolean  function  of  data  values,  such  as  ‘the  salary  of  Jane  is  greater  than 
40K’.  Evaluation  of  condition  does  not  produce  any  side  effects,  i.e.,  does  not  change  the  database 
state.  A  condition  may  be  valid  over  an  interval  of  time.  For  example,  ‘the  salary  remains  the  same 
dvuring  the  academic  year’  is  an  assertion  that  can  be  translated  into  an  EGA  rule.  A  database  state 
of  interest  can  be  defined  in  terms  of  a  condition;  conversely,  being  in  a  state  can  be  checked  using 
a  condition.  Gonditions  define  ‘states’  and  hence  axe  used  in  EGA  rules  as  guards  on  transitions. 
A  guarded  transition  fires  when  its  event  occurs  but  only  if  the  guaxd  condition  is  also  true.  For 
example,  when  one  withdraws  from  an  account  (event),  if  the  balance  minus  the  amount  being 
withdrawn  (a  parameter  of  the  event)  is  below  the  minimum  amount  required  (condition),  then 
indicate  the  amount  that  can  be  withdrawn  (action  which  may  lead  to  another  state).  Gonditions 
axe  likely  to  be  formed  on  the  paxameters  that  axe  computed  for  a  particular  event  instance  (in 
addition  to  other  shared  data). 

3.2  Event  Classification 

Events  can  be  organized  into  a  hierarchy  of  event  classes.  Each  event  class  which  has  a  unique  event 
type  [GVK'''93]  and  instances  of  a  class  axe  identified  by  their  class  type  and  time  of  occurrence. 
For  example,  in  a  relational  database,  end-of-delete  is  an  event  class  and  each  delete  operation 
is  an  event  instance  of  this  class,  which  may  have  parameters  such  as  the  relation  name  and  the 
tuples  inserted  in  addition  to  other  class  paxameters. 

^The  implementation  and  syntax  of  Snoop  [Mis91,  CM94a]  are  discussed  in  Section  5  and  Section  6  respectively. 
^The  Snoop  operators  axe  discussed  in  Section  5  with  implementation  details. 
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Events  can  be  broadly  classified  as  follows; 

1.  Primitive  events  :  Events  that  are  pre-defined  in  the  system  by  using  primitive  event  ex¬ 
pressions  and  event  modifiers.  A  mechanism  for  the  detection  is  assumed  to  be  available 
[AMC93]. 

2.  Composite  events  :  Events  that  are  formed  by  applying  a  set  of  operators  [Kri94]  to  primitive 
and  composite  events. 

3.2.1  Primitive  Events 

Primitive  events  ^e  further  classified  into  database  events,  explicit  events,  and  temporal  events. 
Each  event  (primitive  or  otherwise)  has  a  well-defined  set  of  parameters  that  are  instantiated  for 
each  occurrence  of  that  event. 

Database  events  are  related  to  database  operations  such  as  a  transaction,  and  in  the  relational 
model,  they  can  be  retrieve,  insert,  update  and  delete. 

Explicit  events  are  those  events  that  are  detected  and  signaled  along  with  their  parameters  by 
application  programs  and  are  only  managed  by  the  system.  Prior  to  their  usage,  explicit  events 
and  their  formal  parameters  need  to  be  registered  with  the  system. 

Temporal  events  are  related  to  time  and  are  of  two  types:  absolute  and  relative.  Absolute 
events  map  to  discrete  points  on  the  time  line  (e.g.,  at  10  a.m.),  whereas  relative  events  are  defined 
with  respect  to  an  explicit  reference  point  (e.g.,  one  hour  after  an  event  e  occurs,  where  e  is  either 
a  primitive  or  a  composite  event).  An  absolute  time  is  composed  of  the  following  six  fields:  second 
(ss),  minute  (mm),  hour  (hh),  day  (DD),  month  (MM),  and  year  (YY),  and  it  is  specified  in  the 
form  of  [hh:mm:ss/MM/DD/YY].  A  relative  time  is  a  concatenation  of  one  or  more  time  units  and 
has  the  form:  [2  months  +  10  days  +  5  hrs  -f  10  mins  +  49  secs].  Both  absolute  and  relative  can 
have  wildcard  (‘?’,  or  ‘*’)  in  their  expressions  to  represents  multiple  times. 

3.2.2  Composite  Events 

A  composite  event  expression  is  defined  as  an  event  expression  formed  by  using  a  set  of  primitive 
event  expressions,  event  operators  (described  in  section  3.2.1),  and  composite  event  expressions 
constructed  up  to  that  point.  A  composite  event  is  an  event  obtained  by  the  application  of  an 
event  modifier  to  a  composite  event  expression.  By  default,  the  end-of  event  modifier  is  assumed. 
The  event  classification  is  shown  in  Figure  2. 
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Transaction  /  Access  Insert  Delete  Update 
Procedure/ 

Function 

Figure  2:  Event  Classification 
3.3  Snoop  Event  Operators 

Snoop  provides  a  number  of  operators  for  constructing  composite  events.  Below,  we  summarize  the 
operators  supported  in  Snoop  with  brief  explanations: 

1.  AND  (A):  Conjunction  of  two  events  E^and  E2,  denoted  E1AE2,  occurs  when  both  Ei  and 
E2  occur  (the  order  of  occurrence  of  Ei  and  E2  is  irrelevant). 

2.  OR  (V):  Disjunction  of  two  events  Ei  and  E2,  denoted  E1VE2,  occurs  when  either  Ei  or  E2 
occurs  (simultaneous  occurrence  is  currently  excluded). 

3.  SEQ  (»):  Sequence  of  two  events  Ei  and  E2,  denoted  Ei>E2.,  occurs  when  E2  occurs 
provided  Ei  has  already  occiured.  This  implies  that  the  time  of  occurrence  of  Ei  is  guaranteed 
to  be  less  than  the  time  of  occurrence  of  E2- 

4.  NOT  (-•):  The  NOT  operator,  denoted  ->{E2)[Ei,  E^],'  detects  the  non-occurrence  of  the 
event  E2  in  the  closed  interval  formed  by  Ei  and  E3.  Note  that  this  operator  is  different  from 
that  of  !E  (a  unary  operator  in  Ode  [GJS92b])  which  detects  the  occurrence  of  any  event 
other  than  E  (the  complement  set  semantics  is  used).  It  is  rather  similar  to  the  SEQ  operator 
except  that  E2  should  not  occur  between  Ei  and  E3. 

5.  ANY:  The  conjunction  event,  denoted  by  ANY(m,  Ei,  E2,  ...En)  where  m<=n,  occurs 
when  m  events  out  of  the  n  distinct  events  specified  occur,  ignoring  the  relative  order  of  their 
occurrences. 
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6.  A:  One  can  express  the  occurrence  of  an  aperiodic  event  in  the  half-open  interval  formed 
by  El  and  £^3'*.  An  aperiodic  event  is  denoted  as  A{£i,  £2,  E3),  where  £1,  £2  and  £3  are 
arbitrary  events.  The  event  A  is  signaled  each  time  £2  occurs  during  the  half-open  interval 
defined  by  £1  and  £3. 

7.  A*:  This  is  a  cumulative  variant  of  A  expressed  as  j4*(£i,  £2,  £3)-  It  is  useful  when  a 
given  eyent  is  signaled  more  than  once  during  a  given  interval,  but  rather  than  detecting  the 
event  and  firing  the  rule  every  time  the  event  occurs,  the  rule  has  to  be  fired  only  once.  A* 
is  detected  when  £3  occurs  and  accumulates  the  occurrences  of  £2  in  the  half-open  interval 
formed  by  £1  and  £3. 

8.  P:  A  periodic  event  is  defined  as  an  event  E  that  repeats  itself  within  a  constant  and  finite 
amount  of  time.  It  is  denoted  as  P(£i,  £2,  £3),  where  £1  and  £3  are  any  types  of  events 
and  £2  is  a  relative  temporal  event.  P  occurs  for  every  amount  of  time  specified  with  the 
time  string  of  £2  in  the  half-open  interval  (£1,  £3].  The  time  string  should  be  positive  and 
should  not  have  any  wild  card  to  prohibit  continuous  occurrences  of  P. 

9.  P*:  P*  is  a  cumulative  variant  of  P  and  is  denoted  by  P*(£i,  £2,  £3).  P*  occurs  only  once 
when  £3  occurs  and  accumulates  the  time  of  occurrences  of  the  periodic  event  whenever  £2 
occurs. 

10.  PLUS  (+):  Sequence  of  an  event  £1  after  a  time  interval  TI,  denoted  £1  -f  [TI]  occurs  when 
TI  time  units  are  elapsed  after  £2  occurs. 

3.4  Parameter  Contexts 

The  notion  of  parameter  contexts  is  introduced  in  Snoop  to  captmre  application  semantics  for 
computing  the  parameters  or  consuming  event  occurrences  (of  composite  events)  when  they  are  not 
unique.  Snoop  identifies  four  parameter  contexts  that  are  useful  for  a  wide  range  of  applications. 
These  contexts  are  precisely  defined  using  the  notion  of  initiator  and  terminator  events.  An  initiator 
of  a  composite  event  is  a  constituent  event  which  can  start  oije  detection  of  the  composite  event, 
and  a  terminator  is  a  constituent  event  which  can  detect  an  occurrence  of  the  composite  event. 

•  Recent:  In  this  context,  not  all  occurrences /instances  of  a  constituent  event  will  be  used  in 
detecting  a  composite  event,  only  the  most  recent  occurrence  of  the  initiator  for  any  event 
that  has  started  the  detection  of  that  event  is  used.  When  an  event  occurs,  the  event  is 
detected  and  all  the  occurrences  of  events  that  cannot  be  the  initiators  of  that  event  in  the 
future  are  deleted  (or  flushed).  Furthermore,  an  initiator  of  an  event  (primitive  or  composite) 
will  continue  to  initiate  new  event  occurrences  until  a  new  initiator  occurs. 

‘*The  interval  can  either  be  (tj0cc(£!i),  t-0cc(£l2)]  or  [t_occ(£li),  t-OCc(S2)). 
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•  Chronicle:  In  this  context,  for  an  event  occurrence,  the  initiator,  terminator  pair  is  unique 
(after  a  detection,  the  initiator  and  the  terminator  are  flushed).  The  oldest  initiator  is  paired 
with  the  oldest  terminator  for  each  event  (i.e.,  in  chronological  order  of  occurrence). 

•  Continuous:  In  this  context,  each  initiator  of  an  event  starts  the  detection  of  that  event 
and  is  saved  until  a  terminator  occurs.  A  terminator  is  paired  with  every  initiator.  Thus 
the  terminator  may  detect  one  or  more  occurrences  of  the  same  event.  The  initiator  and 
the  terminator  are  discarded  after  an  event  is  detected.  This  context  is  especially  useful  for 
tracking  trends  of  interest  on  a  sliding  time  point  governed  by  the  initiator  event. 

•  Cumulativte:  In  this  context,  all  occurrences  of  an  event  type  are  accumulated  as  instances  of 
that  event  until  a  terminator  occurs  (that  is,  the  event  is  detected).  Thus  all  the  occurrences 
of  the  event  detection  are  packaged  in  based  on  their  order  of  occurrences.  Whenever  an 
event  is  detected,  all  the  occurrences  that  are  used  for  detecting  that  event  are  deleted. 
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4  Architecture 


This  section  discusses  the  architecture  of  Sentinel,  an  active  OODBMS  being  implemented  at  the 
University  of  Florida.  Below,  we  briefly  introduce  the  Open  OODB  and  the  Sentinel  architectures. 

4.1  Open  OODB 

The  Open  OODB  project  [WBT92,  OOD93],  was  initiated  by  Texas  Instruments  to  build  a  high 
performance,  multi-user  object-oriented  database  management  system  (OODBMS)  in  which  the 
database  functionality  can  be  tailored  for  the  diverse  needs  of  applications.  The  system  provides 
an  expandable  frEunework  that  can  also  serve  as  a  common  testbed  for  research  by  database, 
framework,  environment  and  system  developers  who  intend  to  experiment  with  difierent  system 
architectures  or  components.  It  facilitates  incorporation  of  new  components  from  smaller  groups 
lacking  resources  to  build  an  entire  database  system.  The  Open  OODB  describes  the  design  space 
of  OODB  and  builds  an  architectural  framework  that  enables  configuring  independently  useful 
modules  to  form  an  Object  Oriented  Database  Management  System.  The  Open  OODB  system 
architecture  is  divided  into: 

•  A  meta-architecture  consisting  of  a  collection  of  kernel  modules  and  definitions  providing  the 
infrastructure  for  creating  environments  and  boundaries,  specifying  and  implementing  event 
extensions  and  regularizing  interfaces  among  modules. 

•  An  extensible  collection  of  policy  manager  modules  which  provide  functionality  to  the  system. 

Since  Open  OODB  is  an  object-oriented  front  end,  it  uses  Exodus  as  its  underlying  storage 
manager  through  an  interface.  Open  OODB  supports  multiple  application  programming  languages 
(C+-f-  and  Lisp)  and  has  extended  these  languages  to  support:  persistence,  concurrent  transactions, 
and  schema  evolution  to  developers’  existing  programming  environments.  These  extensions  allow 
programmers  to  stay  within  familiar  programming  paradigms  and  languages.  Open  OODB  allows 
developers  to  define  a  behavioral  extension  of  events,  which  is  an  application  of  an  operation  to 
a  particular  set  of  objects.  To  perform  these  extensions  we  ‘must  be  able  to  interrupt  or  trap 
operations.  Thus,  the  trapping  mechanism  combined  with  the  protocol  for  permitting  the  entity 
performing  the  trapping  to  invoke  an  arbitrary  extension  is  known  as  a  sentry.  The  primary  function 
of  sentries  is  to  detect  events  interacting  with  objects  and  to  pass  control  to  a  policy  manager  which 
controls  and  performs  the  actual  extension  if  it  is  determined  that  an  event  should  be  extended. 
The  sentry  manager  is  used  for  specifying  events  to  be  extended  and  is  responsible  for  deploying 
sentries  to  detect  extended  events. 

Sentinel  uses  Open  OODB  as  its  platform.  The  primary  class  OODB  has  been  extended  to 
have  reactive  capability  and  the  sentry  mechanism  is  used  to  build  wrapper  functions  wherever 
necessary. 
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4.2  Sentinel 


Sentinel  is  based  on  the  Open  OODB  [WBT92,  OOD93].  Sentinel’s  EGA  rule  support  enhances 
the  Open  OODB  from  a  passive  OODB  to  an  active  one. 


Application  coda  including 
EGA  rule  specification 


Figure  3:  Sentinel  Architecture 


Figure  3  indicates  the  functional  modules  of  the  open  OODB  and  the  extensions  for  Sentinel. 

These  extensions  include: 

•  Primitive  event  detection:  A  method  can  be  specified  as  a  primitive  event,  and  the  occurrences 
of  the  primitive  event  are  notified  to  the  local  event  detector  when  the  method  is  invoked. 
We  have  modified  the  Open  OODB  preprocessor  to  wrap  the  method  invocation  with  the 
notifications  to  the  local  event  detector  in  order  to  detect  primitive  events. 

•  Composite  event  detection:  Composite  events  defined  within  an  application  is  detected  by 
using  a  sequence  of  primitive  events  detected  according  to  the  specified  parameter  context 
of  the  composited  event  [Kri94,  CKAK94].  Each  Open  OODB  application  has  its  own  local 
event  detector. 

•  Global  event  detection:  The  events  of  inter-applications  is  detected  by  the  global  event  detec¬ 
tor.  The  global  event  detector  communicates  with  the  local  event  detectors  through  RPC  and 
socket-basec  communication  to  detect  global  events  (This  is  currently  being  implemented). 

•  Nested  transactions:  The  transaction  manager  in  the  client  address  space  supports  nested 
transactions  [MosSl,  Bad93]  for  concurrent  execution  of  rules.  Light  weight  processes  are 
used  both  for  prioritized  and  concurrent  rule  execution. 
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•  Rule  debugger:  The  rule  debugger  [Zho95,  CTZ95]  allows  visualization  of  interactions  among 
rules,  rules  and  events,  and  rules  and  database  objects. 

•  Rule  editor:  The  rule  editor  allows  the  user  to  add  external  rules  at  run  time.  It  communicates 
with  the  local  event  detector  to  edit  rules  and  events.  A  graphical  user  interface  for  the  rule 
editor  is  currently  under  development. 

•  Snoop  preprocessor:  The  Snoop  preprocessor  transforms  the  EGA  rules  specified  either  as 
part  of  a  class  definition  or  as  part  of  an  application.  The  preprocessor  converts  the  high-level 
user  specification  of  EGA  rules  specified  in  Snoop  language  [GM94a]  into  appropriate  G-b-1- 
code  for  evelit  detection,  parameter  computation,  and  rule  execution. 


Figure  4  shows  how  the  class  lattice  of  the  Open  OODB  has  been  extended.  The  classes  outside 
the  dotted  box  have  been  introduced  for  providing  active  capability.  This  figure  also  shows  the 
kernel-level  enhancements  to  the  Open  OODB  modules  to  accommodate  nested  subtransactions. 


SENTINEL  CLASS  LATTICE 


OpM  OODB  NESTED  TRANSACTION  MANAGER 


,  TRANSACTION  MGR 


SYNCHRONIZATION 


EXODUS  SERVER 
(Top  level  transaction 
info  held  here) 


Figure  4:  Glass  lattice  and  transaction  manager  of  Sentinel 


Figure  5  shows  the  control  fiow  for  supporting  event  detections  and  rule  executions.  The 
Sentinel  primitive  event  detection  mechanism  is  based  on  the  design  proposed  in  [AMG93].  The 
occurrences  of  the  primitive  events  are  signaled  with  the  appropriate  parameter  collections  by 
wrapping  notifications  of  the  primitive  event  method.  Both  primitive  and  local  composite  events 
axe  signaled  as  soon  as  they  are  detected. 

Each  application  has  a  local  event  detector.  When  a  primitive  event  occurs  it  is  sent  to  the  local 
event  detector  and  the  application  waits  for  the  signaling  of  rules  that  are  detected  in  the  immediate 
mode.  The  global  event  detector  communicates  with  the  local  event  detectors  for  receiving  events 
detected  locally  and  with  the  application’s  global  event  handler  for  signaling  the  detection  of  global 
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Figiire  5:  Local  and  GlobaJ  Event  Detector  Architecture 


events  for  executing  tasks  based  on  global  events.  There  is  a  clean  separation  between  the  events 
detected  by  the  local  event  detector  and  the  global  event  detector. 
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5  Design  and  Implementation  of  Local  Event  Detector 

Events  are  detected  by  a  local  event  detector  (LED)  in  Sentinel.  In  this  chapter  we  discuss  the 
implementation  details  of  LED,  including  the  constructing  an  event  graph,  handling  of  temporal 
events,  and  implementation  of  Snoop  operators  A,  A*,  P,  and  P*. 

5.1  Event  Graph 

An  event  graph  is  a  graph  constructed  to  reflect  the  primitive  and  composite  events  declared  in 
an  application.  Each  event  is  represented  as  an  event  node  in  the  graph,  and  the  event  nodes  are 
connected  by  thek  subscription  ®  relationships.  An  internal  node  of  the  event  graph  represents  a 
composite  event,  and  a  leaf  node  represents  a  primitive  event. 

5.1.1  Primitive  Event  Node 

A  primitive  event  is  a  leaf  node  of  the  event  graph  and  is  a  subscriber  of  a  method.  A  primitive  event 
node  has  fom:  attributes:  method  signature,  event  modifier,  instance  number,  and  object  address. 
Method  signature  stores  the  unique  signature  (return  type,  name  and  arguments  of  the  method  )  of 
a  method  declared  as  a  potential  event.  If  a  primitive  event  is  a  temporal  event,  it  keeps  the  ascii 
time  expression  of  the  temporal  event  instead  of  a  method  signature.  Event  modifier  {begin  or  end) 
[CM94a]  tells  when  the  primitive  event  gets  a  notification  from  its  associated  method.  It  can  be  at 
the  begirming  or  at  the  end  of  method  invocation.  The  primitive  event  occurs  at  the  notification 
time.  Each  occurrence  of  the  primitive  event  has  a  imique  instance  number.  If  the  primitive  event 
is  declared  for  a  specific  object  of  a  reactive  class,  the  attribute  object  address  has  the  address  of 
the  specific  object,  otherwise  it  has  a  null  pointer.  The  binding  between  a  primitive  event  and  a 
method  is  specified  with  an  event  modifier  by  a  user  in  the  Snoop  language.  In  the  example, 
event  begin  (el)  int  sell_stock(int  number) ; 
the  primitive  event  el  is  bound  to  a  method  named  sell^tock  and  the  method  notifies  its  occurrence 
at  the  beginning  of  its  invocation.  Composite  events  and  rules  can  subscribe  any  number  of  primitive 
events.  These  events  and  rules  are  kept  cither  in  event-list  or  in  rule-list  of  the  primitive  event.  Leaf 
nodes  pass  the  primitive  events  immediately  to  their  parent  nodes  as  the  semantics  of  all  contexts 
are  identical  for  primitive  events. 

5.1.2  Composite  Event  Node 

A  composite  event  is  defined  using  one  or  more  Snoop  operators  and  primitive  events  using  the 
BNF.  The  local  event  detector  generates  an  event  tree  whose  root  node  represents  the  composite 
event.  Event  trees  in  an  application  are  merged  to  form  an  event  graph  for  detecting  a  set  of 
composite  events.  This  prevents  detecting  common  sub-events  multiple  times,  thereby  reducing 

®An  object  can  get  notifications  when  methods  of  other  object’s  are  executed.  We  call  this  notification  relationship 
subscription.  The  notifiable  object  becomes  a  subscriber  of  the  notifying  object. 
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Figure  6:  Event  trees 

storage  requirements.  A  sequence  of  constituent  event  occurrences  makes  a  composite  event  occur. 
Since  event  occurrences  happen  over  a  period  of  time,  it  is  necessary  to  store  the  occurrence  of 
each  event  and  save  its  parameter  lists  to  detect  composite  event  occurrences.  Each  operator  node 
which  is  the  root  node  of  an  event  tree  has  storage  to  save  these  event  occurrences.  The  information 
is  saved  separately  according  to  the  parameter  contexts  which  are  applicable  to  composite  events. 
Multiple  contexts  can  be  set  to  an  operator  node,  and  these  contexts  do  not  interfere  with  each 
other  while  the  composite  event  is  detected.  The  stored  information  is  flushed  or  remains  after  an 
occurrence  of  the  composite  event  according  to  parameter  context.  Similar  to  a  primitive  event,  a 
composite  event  (node)  has  two  linked  lists,  one  for  its  event  subscribers  and  the  other  for  its  rule 
subscribers.  Figure  6  shows  a  few  event  trees. 

5.1.3  Local  Event  Detector 

An  event  detector  is  implemented  as  a  class,  and  we  have  a  single  instance  of  this  class  per  ap¬ 
plication  (termed  local  event  detector).  A  local  event  detector  has  a  linked  list  whose  nodes  hold 
one  reactive  class  of  an  application.  Each  node,  in  turn,  has  two  linked  lists,  begin  Jist  and  endJist. 
The  lists  have  the  subscribers  (here,  they  are  primitive  events  which  are  bound  to  one  of  methods 
in  the  class)  to  be  notifled  at  the  beginning  or  the  end  of  these  methods’s  invocations.  By  default 
a  subscriber  is  inserted  in  the  end-list  if  it  does  not  specify  when  to  be  notified.  This  organization 
reduces  the  search  which  is  based  on  the  class.  However,  search  for  the  class  is  sequential.  An  event 
graph  is  constructed  while  the  event  trees  of  composite  events  in  the  application  are  built  by  their 
subscribing  relations.  The  event  graph  is  connected  to  the  reactive  class  list  through  primitive-leaf 
nodes.  A  primitive-leaf  node  is  associated  with  a  method  which  belongs  to  one  of  the  reactive  class 
nodes.  This  connected  event  graph  and  the  reactive  list  constitute  a  local  event  detector  for  the 
application.  A  primitive  event  constructor  registers  itself  to  the  reactive  class  list  as  a  subscriber  of 
a  method  in  the  list.  Figure  7  shows  how  primitive  leaf  nodes  of  an  event  graph  are  connected  to 
a  reactive  class  list.  The  reactive  class  name  is  “STOCK”  and  it  has  three  methods:  “sell_stock” , 
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EVENT  GRAPH 


REACmVE  CLASS  LIST 

Figure  7:  An  Event  Graph  connected  to  a  reactive  class  list 

“buyjtock”,and  “set_price”.  Figure  8  shows  an  event  detector  structure. 

5.1.4  Detecting  Events 

The  methods  that  can  generate  primitive  events  are  modified  by  the  wrapper  class  methods  using 
the  sentry  feature  of  the  Open  OODB  system  while  preprocessing  the  application  program.  The 
Open  OODB  preprocessor  was  modified  to  add  code  for  parameter  collection  and  notification  to  the 
event  detector  while  preprocessing  the  application  program.  When  a  method  registered  to  the  local 
event  detector  is  invoked,  notifications  of  this  invocation  are  signaled  both  at  the  beginning  and  at 
end  of  the  method  to  the  local  event  detector  with  method  signature,  class  name,  event  modifier, 
parameter  list  of  the  method,  and  a  reactive  object  if  this  event  is  declared  as  an  instance-level 
event.  A  parameter  list  is  formed  right  before  notification  with  the  parameters  of  the  method.  The 
parameter  list  keeps  names,  types,  and  values  of  the  parameters.  With  the  class  name,  the  local 
event  detector  searches  the  list  of  the  reactive  classes.  If  there  exists  no  node  with  the  same  name, 
it  causes  an  event-raising  error.  If  there  is  a  node  with  the  same  name,  then  it  traverses  either 
begin-list  or  end-list  according  to  the  event  modifier  that  came  with  the  notification.  Up  to  this 
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Figure  8:  An  Event  Detector 
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point,  every  primitive  event  in  any  one  of  the  lists  is  notified  regardless  of  the  event  method  to 
which  the  primitive  event  is  bound.  A  primitive  event  node  keeps  the  method  signature  and  the 
reactive  object  if  any.  If  the  notification  that  came  from  the  event  method  has  a  reactive  object, 
the  primitive  event  node  compares  these  two  reactive  objects  as  well  as  their  method  signatures. 
White  spaces  are  ignored  when  the  comparison  taJces  place.  Only  when  both  match  it  propagates 
its  occurrence  to  its  subscribers,  which  can  be  composite  event  or  rules.  Every  time  the  primitive 
event  occurs,'  its  unique  instance  number  is  given,  its  occurrence  time  is  set  in  the  parameter  list, 
and  further  notifications  go  to  its  subscribers.  As  defined  earlier,  a  composite  event  is  an  event  tree 
and  the  root  of  the  event  tree  is  one  of  the  Snoop  operators.  The  node  maintains  the  occurrence 
of  its  constituent  fevent  occurrences  with  their  parameter  lists  which  are  stored  separately  for  each 
context  set  to  the  node.  Whenever  it  is  notified  by  one  of  its  constituents,  the  node  checks  the 
status  of  its  constituents’  occurrences.  We  call  the  constituent  event  instance  that  causes  the  start 
of  an  occurrence  of  the  composite  event  an  initiator,  and  the  constituent  event  instance  that  causes 
the  detection  of  the  occurrence  a  terminator.  If  the  composite  event  occurs  by  the  last  notification, 
it  is  detected,  and  further  notifications  are  sent  to  its  subscribers.  The  parameter  list  is  recomputed 
to  hold  event  traces  from  method  invocation  to  this  new  occurrence  and  gets  the  current  time  as 
a  new  occurrence  time.  After  the  detection  and  the  notifications,  the  parameter  list  held  in  the 
operator  storage  will  be  flushed  or  maintained  for  the  next  detection  of  an  event  according  to  the 
operator  semantics.  Any  events  or  rules  can  unsubscribe  their  constituent  events  even  after  the 
event  graph  is  constructed.  This  unsubscription  does  not  change  the  event  graph;  only  events  or 
rules  are  deleted  from  the  subscriber  lists.  Resubscribing  is  as  easy  as  unsubscribing:  just  insert 
the  new  subscriber  in  the  list.  No  restructuring  of  the  event  graph  is  needed. 

5.2  Temporal  Event 

5.2.1  Handling  Temporal  Event 

Unlike  the  other  types  of  primitive  events,  temporal  events  need  a  temporal  event  handler  as  well 
as  a  local  event  detector.  One  temporal  event  handler  is  generated  per  application.  The  tem¬ 
poral  event  handler  consists  of  classes,  Time.queueJtem,  Time.queue,  and  Time-queueJiandler. 
Time-queueJtem  is  responsible  for  converting  a  time  expression  into  a  numerical  representation. 
Time.queue  handles  these  numerical  temporal  representations  in  timely  order,  and  Time_queueJiandler 
provides  an  interface  between  local  event  detector  and  temporal  event  handler,  and  manages  time 
queues  and  the  timer.  Two  Time.queues  are  created  when  Time-queueJiandler  is  constructed. 
Converting  a  Timestring  into  a  Numeric  Time  Expression:  A  temporal  event  is  created 
by  giving  a  unique  time  expression  and  its  identification  number,  add-item,  one  of  the  functions 
of  Time-queue-handler,  carries  the  time  expression  and  the  identification  number  to  the  temporal 
event  handler.  Examples  of  declaring  temporal  events  are  below: 

Time_queue_handler  tqh; 
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tqh. add_itein(“  12: 00: 00/04/18/96 ”  ,  evnt_id  );  /*  absolute  event  */ 
tqh.add.itemC' ‘3  hrs  30  mins”,  evnt_id  );  /*  relative  event  */ 

addJtem  creates  an  instance  of  Time.queue-item  with  the  time  string  and  the  identification  number. 

The  time  string  is  converted  into  a  numerical  time  expression.  This  conversion  is  directed  by  the 
function  called  convJs  if  it  is  an 'absolute  temporal  string,  or  by  the  function  called  conv.rel  if  it  is 
a  relative  temporal  string.  Once  the  time  string  is  decomposed  into  time  units  from  second  to  year, 
these  decomposed  values  are  converted  into  integer  values.  If  a  time  unit  includes  a  wildcard,  the 
wildcard  is  replaced  with  the  lowest  value  according  to  its  position  when  the  conversion  takes  place. 

The  current  time  is  added  to  the  converted  values  if  it  is  a  relative  case.  The  results  of  the  conversion 
axe  held  in  the  array  tm.hold  where  each  element  represents  a  time  unit.  These  constituent  integer 
values  are  copied  to  a  tm  structure  which  is  declared  in  <time.h>  for  representing  real  time,  and 
the  values  in  the  tm  are  converted  into  a  time  value  that  represents  the  number  of  seconds  since 
Jan.  1,  1970,  00:00,  Greenwich  Mean  Time.  This  final  converted  result  is  stored  into  the  conv.time 
data  member,  which  is  a  type  of  timeJ  (long  integer).  Managing  Time  Queues:  The  temporal 
event  handler  has  two  time  queues-tirrae^  and  presJtems-  generated  when  the  handler  is  created. 

A  time  queue  is  semaphore-protected;  that  is,  the  time  queue  constructor  requests  a  semaphore 
for  the  queue  from  the  operating  system,  and  the  semaphore  is  used  to  serialize  additions  to  and 
deletions  from  the  queue.  The  timeq  is  an  ordered  queue  of  time  queue  items.  Time  queue  items 
are  queued  in  timely  order  before  they  are  set  to  the  timer.  If  the  item  has  an  obsolete  time,  it  is 
not  queued.  The  presJtems  queue  is  used  to  handle  multiple  temporal  events  which  have  the  same 
expiration  times.  The  front  item  of  timeq  is  moved  into  the  presJtems  before  its  time  is  set  to  the 
timer  and  stays  there  until  the  time  expires:  the  item  in  presJtems  is  currently  set  to  the  timer  and 
dequeued  when  the  time  expires.  Multiple  items  with  the  same  expiration  time  are  moved  together 
into  presJtems.  If  a  new  item  is  queued  into  timeq  with  an  earlier  time  than  that  of  the  item  in 
the  presJtems,  then  they  are  swapped  and  the  timer  is  reset  with  the  earlier  time. 

Setting  a  Timer:  The  time  of  the  item  in  presJtems  is  set  to  the  timer.  Even  though  there 
is  more  than  one  item  with  the  same  time  in  the  queue,  the  time  is  set  to  the  timer  only  once.  If 
the  time  becomes  obsolete  while  it  stays  in  the  timeq,  the  item  is  not  set  and  the  next  time  is  set 
to  the  timer.  Setting  the  timer  is  done  by  calling  the  system  function  setitimer. 

Processing  of  Alarm  Clock  Signal:  When  the  temporal  event  handler  is  created,  Time-queueJiandler 
constructor  installs  a  signal  handler  to  give  an  alarm  clock  signal  by  calling  a  system  function,  sig¬ 
nal.  A  signal  is  sent  when  the  time  on  the  timer  expires  to  the  signal  handler  of  the  temporal 
event  handler.  The  signal  handler  calls  process,  which  is  a  method  of  Time.queueJiandler.  This 
function  dequeues  all  items  in  the  presJtems  and  gives  them  notifications  with  the  expiration  time. 
Repetitive  items  are  updated  with  the  next  higher  value  and  queued  into  timeq  unless  updating  is 
no  longer  necessary.  The  new  front  item  in  timeq  is  moved  into  presJtems  and  is  set  to  the  timer. 
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Figure  9  shows  how  a  time  item  is  handled  inside  of  the  temporal  event  handler. 

5.2.2  Integration  of  a  Temporal  Event  Handler  into  a  Local  Event  Detector 

As  other  types  of  primitive  events,  temporal  events  are  detected  through  an  event  graph.  The 
temporal  event  handler  and  the  event  graph  is  connected  through  primitive  temporal  events.  When 
the  first  temporal  event  is  declared,  a  reactive  class  node  is  inserted  into  the  reactive  class  list  of  the 
local  event  detector  with  the  name  “TEMPORAL”  instead  of  a  reactive  class  name.  A  primitive 
event  is  declared  with  a  time  expression  and  is  listed  in  a  subscribers’  list  as  it  is  wdth  a  method 
signature.  Since  the  time  expression  is  used  like  a  method,  the  time  expression  should  be  unique. 
The  end-o/ event  modifier  is  chosen  for  temporal  event  by  default.  Figure  10  shows  how  temporal 
events  are  integrated  into  a  local  event  detector  (this  figure  only  shows  the  reactive  class  list  and 
primitive  events  of  the  local  event  detector).  Once  declared,  a  primitive  temporal  event  checks  the 
type  of  time  expression.  If  it  is  absolute,  a  time  queue  item  is  created  with  the  time  string  and 
pushed  into  the  time  queue.  If  it  is  relative,  the  time  queue  item  is  created  when  its  relative  event 
occurs  rather  than  by  the  primitive  event.  Relative  time  expression  is  used  in  P,  P*,  and  PLUS 
operators.  Since  a  relative  time  expression  has  to  know  which  is  its  relative  event,  a  time  queue 
item  is  created  with  the  event  number  of  the  relative  event  as  well  as  the  time  string  while  an 
absolute  time  expression  has  0  as  its  event  number.  When  the  timer  signals  that  a  time  is  finished 
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NOTinCATION  FROM  TEMPORAL  EVENT  HANDLER. 


PRIMmVE  EVENT 


REACTIVE  CLASS  NODE 
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EL  :  EVENT  SUBSCRIBING  UST  RL  •  R1  n£  SUBSCRIBING  LIST 

Figure  10:  Integration  of  Temporal  Event  into  a  Local  Event  Detector 


on  the  timer,  the  temporal  event  handler  catches  the  signal  and  notifies  the  occurrence  to  every 
time  queue  item  in  pres-items  with  the  occurrence  time.  A  time  queue  item  creates  a  parameter  list 
which  holds  the  occurrence  time  and  its  event  number  that  were  given  from  its  referencing  primitive 
event.  The  event  number  is  added  to  the  end  of  the  parameter  list.  The  notifications  go  to  the  leaf 
nodes  of  the  event  graph.  The  primitive  leaf  nodes  have  these  time  expressions  instead  of  method 
signatmres.  Further  notification  goes  up  the  event  graph  through  the  events  that  subscribe  the 
temporal  event.  Temporal  event  notification  from  the  temporal  event  handler  to  the  event  graph 
is  sent  like  a  method  connected  to  a  primitive  event  except  for  a  few  more  steps  to  reach  the  event 
graph. 


5.3  Newly  Implemented  Snoop  Operators 

This  section  describes  the  implementation  details  of  PLUS,  A,  A*,  P,  and  P*  with  their  algorithms. 

1.  PLUS  (+):  PLUS  is  used  with  relative  time  expressions.  A  PLUS  operator  subscribes  two 
events  Ei  and  E2,  where  Ei  can  be  any  types  of  events  and  E2  should  be  a  relative  temporal 
event.  Originally  E2  is  specified  as  a  relative  time  expression  from  a  user.  The  Snoop 
preprocessor  declares  it  as  a  relative  temporal  event.  A  relative  temporal  event  occurs  after 
the  amount  of  time  expressed  by  the  time  string  since  an  instance  of  Ei  occurs.  Unlike 
absolute  temporal  events  which  produce  time  queue  items  when  they  are  declaxed  as  primitive 
events  by  the  Snoop  preprocessor,  relative  temporal  events  produce  time  queue  items  when 
an  E\  instance  occurs.  Each  time  queue  item  carries  an  identification  number  which  is  the 
identification  number  of  its  referencing  Ei,  and  passes  this  number  to  E2.  When  the  PLUS 
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1.  El  occurs.  The  instance  number  of  El  is  passed  to  E3. 

2.  Ask  temporal  event  handler  to  produce  a  time  queue  item  with  the  instance  number  of  El  and  the  time  expression  of  E2 

3.  Notify  that  the  time  has  passed.  Event  number  of  El ,  time  expression,  and  the  occurrence  time  are  passed. 

4.  Notify  to  E2. 

5.  E2  occurs.  The  instance  number  of  El  and  the  occurrence  time  are  passed  in  the  parameter  of  E2. 

6.  Check  the  instance  numbers  from  El  and  E2.  If  they  are  matched,  notify  the  occurrence  of  E3  to  the  subscibers. 

Figure  11:  PLUS  Operator 

operator  gets  the  occurrence  notification  from  E2,  it  checks  the  identification  number  of  the 
instance  of  E2  to  verify  that  the  matching  instance  is  still  valid.  The  identification  number 
is  carried  in  the  last  parameter  of  the  parameter  list  brought  with  the  notification.  Any  E2 
occmrrence  whose  identification  number  cannot  be  found  in  the  list  of  Ei  is  ignored.  The 
following  Figure  11  shows  how  the  PLUS  operator  communicates  with  the  temporal  event 
handler  to  handle  its  relative  temporal  event. 

The  algorithm  of  detecting  relative  temporal  events  follows  where  ei  represents  an  instance 
of  Ei. 


PLUS(.Bi,  E2): 

PROCEDURE  plus_recent(  Ei,  parameterJist)  /*  Recent  */ 
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if  left  event  el  is  signaled 

get  the  terminator  ID  of  el 

create  a  time  queue  item  with  the  ID  and  the  time  string  of  E2 
replace  el  in  Ei's  list. 

'  if  right  event  e2  is  signaled 
■■■  get  the  ID  of  e2 

if  El ’s  list  is  not  empty  and  the  ID  of  el  and  that  of  e2  are  the  same 
pass  <el,  e2>  to  the  parent  with  a  new  t_occ 

The  local  event  detector  allows  multiple  parameter  context  without  any  interference  to  other 
context  detections.  To  make  this  no-interference  gracefully,  a  PLUS  operator  has  to  check 
which  other  contexts  are  set.  The  priorities  are  given  in  the  order  of  recent,  chronicle,  contin¬ 
uous,  and  cumulative.  By  this  priority  list,  only  the  recent  context  does  not  need  to  check  the 
other  contexts  set.  Chronicle  context  checks  whether  recent  context  is  set;  only  when  recent 
is  not  set  does  the  chronicle  context  produce  a  time  queue  item.  Continuous  context  checks 
whether  recent  or  chronicle  context  is  set.  If  either  one  of  them  is  set,  the  continuous  context 
cannot  produce  a  time  queue  item.  In  the  cumulative  case,  it  should  check  the  other  three 
contexts  to  produce  a  time  queue  item.  Without  context  checking,  multiple  time  queue  items 
are  produced  for  the  same  instance  of  Ei  and  send  unnecessary  notifications  from  the  time 
queue  handler  to  the  event  graph,  thus  increasing  traffic  bandwidth  unnecessarily.  Note  that 
the  validating  identification  number  of  a  temporal  event  and  checking  parameter  contexts 
should  be  done  for  P  and  P*  as  PLUS. 


PROCEDURE  plus_chronicle(Ei,  pajameterJist)  /*  Chronicle  */ 

if  left  event  el  is  signaled 

get  the  terminator  ID  of  el 
if  Recent  context  is  not  set 

create  a  time  queue  item  with  the  ID  and  the  time  string  of  E2 
append  el  in  Ei's  list. 

if  right  event  e2  is  signaled 
get  the  ID  of  e2 

if  Eis  list  is  not  empty  and  the  head’s  terminator  ID 
and  that  of  e2  are  same 

pass  <Ei’s  head,  e2>  to  the  parent  with  a  new  t_occ 
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If  a  Snoop  operator  is  set  to  continuous  context,  a  terminator  may  detect  one  or  more  occur¬ 
rences  of  the  same  event.  In  a  PLUS  operator,  however,  the  terminator,  which  is  a  relative 
temporal  event,  is  only  matched  with  the  initiator  which  gave  birth  to  the  time  queue  item  of 
the  terminator.  Since  the  order  of  relative  temporal  events  is  the  same  as  their  referencing  E\ 
instances,  detections  of  the  continuous  context  are  the  same  as  detection  of  chronicle  context. 


PROCEDURE  plus_continuous(Ei,  parameter  .list)  /*  Continuous  *  / 

if  left  event  el  is  signaled 

get  the  terminator  ID  of  el 

if  Recent  or  Chronicle  context  is  not  set 

create  a  time  queue  item  with  the  ID  and  the  time  string  of  E2 
append  el  in  Ei’s  list. 

if  right  event  e2  is  signaled 
get  the  ID  of  e2 

if  El’s  list  is  not  empty  and  the  terminator  ID  of  the  head  of  the 
list  and  that  of  e2  are  same 

pass  <Ei’s  head,  e2>  to  the  parent  with  a  new  t_occ 
delete  the  head  of  E^s  list 

Note  that  in  implementation,  instead  of  pairing  the  head  of  Ei’s  list  and  e2,  the  el  whose 
terminator’s  ID  is  the  same  as  that  of  the  e2  is  searched  in  the  Ei’s  list  in  case  of  losing  any 
alarm  clock  signal  from  the  signal  handler.  Unmatched  els  are  deleted. 


PROCEDURE  plus_cumulative(Ei,  parameterJist)  /*  Cumulative  *  / 

if  left  event  el  is  signaled 

get  the  terminator  ID  of  el 

if  Recent,  Chronicle,  or  Continuous  context  is  not  set 

create  a  time  queue  item  with  the  ID  and  the  time  string  of  E2 
append  el  in  Ei’s  list. 


if  right  event  e2  is  signaled 
get  the  ID  of  e2 
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if  El’s  list  is  not  empty- 

pass  <all  el’s,  e2>  to  the  parent  with  a  new  t_occ 
flush  El ’s  buffer 


2.  A:  We  can  express  an  aperiodic  event  with  the  A  operator.  The  aperiodic  event  occurs 
whenever  the  second  event,  E2  occurs  during  the  interval  defined  by  the  first  and  the  third 
events.  A  can  occur  zero  or  more  times  (zero  times  either  when  E2  does  not  occur  in  the 
interval  or  when  no  interval  exists  for  the  definitions  of  Ei  and  E3). 


A{Ei,  E2,  E3)  : 

PROCEDURE  a_recent(Ei,  parameter-list)  /*  Recent  */ 

if  left  event  el  is  signaled 
replace  el  in  Ei’s  list. 

if  middle  event  e2  is  signaled 
if  El’s  list  is  not  empty 

pass  <el,  e2>  to  the  parent  with  a  new  t_occ 

if  right  event  e3  is  signaled 
flush  El’s  buffer 


PROCEDUPvE  a_chronicle(Ei,  parameter-list)  /*  Chronicle  */ 

if  left  event  el  is  signaled 
append  el  in  Ei’s  list. 

if  middle  event  e2  is  signaled 
if  El’s  list  is  not  empty 

pass  <Ei’s  head,  e2>  to  the  parent  with  a  new  t-occ 
delete  the  head  of  Ei ’s  list 


if  right  event  e3  is  signaled 
flush  El’s  buffer 
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Prom  the  above  chronicle  pseudo  code,  we  can  notice  that  if  the  previous  E2  instance  makes 
Eis  list  empty,  a  new  occurrence  of  E2  will  be  ignored  even  though  it  occurs  during  the 
interval.  The  same  situation  happens  in  the  continuous  context. 


PROCEDURE  a_continuoils(Ej,  parameterJist)  /*  Continuous  *  / 

if  left  event  el  is  signaled 
append  el  to  Eis  list 

if  middle  event  e2  is  signaled 
if  El’s  list  is  not  empty 

for  every  instance  el  in  El’s  list 

pass  <Ei’s  head,  e2>  to  the  parent  with  a  new  t_occ 
delete  Ei ’s  head 

if  right  event  e3  is  signaled 
flush  El’s  list 


PROCEDURE  a_cumulative(Et,  parameterJist)  /*  Cumulative  */ 

if  left  event  el  is  signaled 
append  el  to  Ei’s  list 

if  middle  event  e2  is  signaled 
if  El ’s  list  is  not  empty 

pass  <all  els,  e2>  to  the  parent  with  a  new  t_occ 
flush  El’s  bufler 

if  right  event  e3  is  signaled 
flush  El ’s  buffer 

In  all  the  contexts  in  A,  the  flrst  occmrence  of  E3  after  the  interval  has  began  terminates  the 
detection  of  A.  A  new  instance  of  E\  is  necessary  to  reinitiate  the  detection. 
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3.  A* :  A*  is  a  cumulative  variant  of  A.  A*  is  detected  only  once  when  E3  occurs  instead  of  being 
detected  every  time  E2  occurs.  When  Eh.  occurs,  the  occurrence  time  of  the  instance  and  the 
values  of  the  parameters  which  E2  carries  are  accumulated  in  E2’s  list.  These  accumulations 
of  E2  instances  require  separate  storage  from  Si’s  list  storage. 

In  recent  context,  an  occurrence  of  E\  flushes  S2’s  list  since  the  new  occurrence  of  Si  starts 
another  recent  interval. 


A*(Si,  S2,  S3): 

PROCEDURE  astar_recent(Si,  parameter-list)  /*  Recent  */ 

if  left  event  el  is  signaled 
replace  el  in  Si’s  list, 
flush  Eh's  buffer 

if  middle  event  e2  is  signaled 
if  Si’s  list  is  not  empty 
append  e2  to  Eh's  list 

if  right  event  e3  is  signaled 
if  Si’s  list  is  not  empty 
if  S2’s  list  is  not  empty 

pass  <el,  all  e2s,  e3>  to  the  parent  with  a  new  t_occ 
flush  Si  and  Sa’s  buffers 

else 

pass  <el,  e3>  to  the  parent  with  a  new  t_occ 
flush  Si’s  buffer 

Unlike  all  contexts  of  A  or  recent  context  of  A*,  in  the  chronicle  context  an  occurrence  of  S3 
does  not  delete  all  previous  S2  occurrences.  The  ith  occurrence  of  Si  and  the  ith  occurrence 
of  S3  are  paired  with  all  S2  occurrences  between  them. 


PROCEDURE  astar_chronicle(Si,  parameterJist)  /*  Chronicle  */ 


if  left  event  el  is  signaled 
append  el  in  Si’s  list. 
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if  middle  event  e2  is  signaled 
if  Eis  list  is  not  empty 
append  e2  to  E2's  list 


-  if  right  event  e3  is  signaled 
'  if  Eis  list  is  not  empty 
if  E2's  list  is  not  empty 

pass  <Eis  head,  all  e2’s  whose  t_occ  are  greater  than 
that  of  EiS  head,  e3>  to  the  parent  with  a  new  t_occ 
delete  the  head  of  Eis  list 

delete  all  e2s  in  E2’s  list  whose  t_occ  is  less  than  that 
of  El's  new  head 
if  El's  list  is  empty 
flush  E2's  buffer 

else 

pass  <^i’s  head,e3>  to  the  parent  with  a  new  t_occ 
delete  head  of  Ei's  buffer 

In  the  continuous  context,  the  flrst  occiurrence  of  E3  flushes  the  lists  of  Ei  and  E2  like  recent 
context. 


PROCEDURE  astcir_continuous(Ei,  parameterJist)  /*  Continuous  */ 

if  left  event  el  is  signalled 
append  el  to  Ei's  list 

if  middle  event  e2  is  signalled 
if  El 's  list  is  not  empty 
append  e2  to  E2's  list 

if  right  event  e3  is  signalled 
if  El’s  list  is  not  empty 
if  E2's  list  is  not  empty 

for  every  instance  el  in  Ei 's  list 

pass  <el,  all  e2  whose  t_occ  is  greater  than  that  of 
el,e3>  to  the  parent  with  a  new  t_occ 
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flush  El's  and  E2's  buffers 


else 

for  each  el  in  Ei ’s  list 

pass  <  el,  e3>  to  the  parent  with  a  new  t_occ 
flush  El's  buffer 

In  cumulative  context,  we  use  only  one  storage  for  both  Ei  and  E2  parameters  since,  when 

E^  occurs  the  first  time,  all  of  the  stored  parameters  will  be  sent  in  their  occurrence  order. 

PROCEDURE  astar.cumulative(Ei,  parameterJist)  /*  Cumulative  */ 

if  left  event  el  is  signalled 

append  el  to  Ei  and  E2's  common  list 

if  middle  event  e2  is  signalled 
if  El's  list  is  not  empty 

append  e2  in  Ei  and  E2's  common  list 

if  right  event  e3  is  signalled 
if  El's  list  is  not  empty 

pass  <all  el  and  all  e2  in  the  common  list,  e3>  to  the  parent 
with  a  new  t_occ 
flush  El  and  E2's  common  buffer 


4.  P:  P  repeats  itself  within  a  constant  and  finite  amount  of  time  expressed  hy  E2.  P  occurs 
in  every  E2  amount  of  time  (that  is,  when  E2  occurs).  It  is  important  to  note  that  the 
time  expression  is  a  constant  and  preferably  does  not  contain  wild  card  specifications  in  all 
fields  because  this  will  result  in  continuous  occurrences  of  P.  Instances  of  E2  play  the  role  of 
terminators.  Except  for  the  first  occurrence  of  P,  the  previous  occurrence  of  E2  is  the  initiator 
of  the  current  occurrence  of  P.  An  occurrence  of  Ei  can  be  an  initiator  only  once  for  the  first 
occurrence  of  E2,  which  has  the  time  queue  item  requested  by  the  Ei  occurrence.  Thus, 
E2  can  be  an  initiator  and  a  terminator.  Checking  parameter  context  to  avoid  unnecessary 
multiples  of  time  queue  item  is  done  like  a  PLUS  operator. 

In  recent  context,  a  P  event  can  be  repeated  until  E3  occurs  by  requesting  creating  a  time 
queue  item  with  the  instance  number  of  the  recent  occurrence  of  Ei  and  the  relative  time 
expression  of  E2  to  the  temporal  event  handler. 
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P(£?l,  E2)  : 


PROCEDURE  p_recent(Ei,  parameterJist)  /*  Recent  */ 

if  left  event  el  is  signalled 
get  the  terminator  ID  of  el 

create  a  time  queue  item  with  the  ID  and  the  time  string  of  Eh. 
replace  el  in  Eis  list. 

if  middle  event  e2  is  signalled 
get  the  ID  of  e2 

if  El's  list  is  not  empty  and  the  ID  of  el  and  that  of  e2  are  same 
create  a  time  queue  item  with  the  ID  of  terminator  ID  of  el 
pass  <el,  e2>  to  the  parent  with  a  new  t_occ 

if  right  event  e3  is  signalled 
flush  El’s  bufi'er 

In  chronicle  context,  initiators  and  the  matching  terminator  should  be  removed  after  they  are 
used.  The  first  occxurrence  of  E2  is  used  as  a  terminator,  and  it  cannot  be  used  as  the  next 
initiator.  Thus,  the  P  repeats  only  once  in  a  half-open  interval. 


PROCEDURE  p_chronicle(Ei,  parameterJist)  /*  Chronicle  */ 

if  left  event  el  is  signalled 
get  the  terminator  ID  of  el 
if  Recent  context  is  not  set 

create  a  time  queue  item  with  the  ID  and  the  time  string  of  E2 
append  el  in  Ei’s  list. 

if  middle  event  e2  is  signalled 
get  the  ID  of  e2 

if  El's  list  is  not  empty  and  the  terminator  ID  of  the  head  of  the 
list  and  that  of  e2  are  same 

pass  <Ei’s  head,  e2>  to  the  parent  with  a  new  t.occ 

if  right  event  e3  is  signaled 
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flush  El ’s  buffer 


Since  the  initiators  of  continuous  and  cumulative  contexts  should  be  removed  after  they  are 
matched  with  terminators,  these  two  contexts  are  also  repeated  only  once.  And  the  instances 
of  E2  have  to  be  matched  only  with  the  instances  of  Ei  which  caused  the  occurrence  of  E2. 
Fof'these  two  reasons,  the  continuous  and  cumulative  contexts  of  a  P  event  are  detected  like 
the  chronicle  context.  That  is,  an  instance  of  Ei  is  matched  with  an  instance  of  E2  to  detect 
a  P  event  only  once  in  time  order. 

\ 

PROCEDURE  p_continuous(Ei,  parameterJist)  /*  Continuous  */ 

if  left  event  el  is  signaled 

get  the  terminator  ID  of  el 

if  Recent  or  Chronicle  context  is  not  set 

create  a  time  queue  item  with  the  ID  and  the  time  string  of  E2 
append  el  in  Ei’s  list. 

if  middle  event  e2  is  signaled 
get  the  ID  of  e2 

if  El’s  list  is  not  empty  and  the  terminator  ID  of  the  head  of  the 
list  and  that  of  e2  are  same 

pass  <Ei’s  head,  e2>  to  the  parent  with  a  new  t.occ 

if  right  event  e3  is  signalled 
flush  El’s  buffer 


PROCEDURE  p_cumulative(Ei,  parameter-list)  /*  Cumulative  */ 

if  left  event  el  is  signalled 
get  the  terminator  ID  of  el 

if  Recent,  Chronicle,  or  Cumulative  context  is  not  set 

create  a  time  queue  item  with  the  ID  and  the  time  string  of  E2 
append  el  in  Ei’s  list. 

if  middle  event  e2  is  signalled 
get  the  ID  of  e2 
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if  El's  list  is  not  empty  and  the  terminator  ID  of  the  head  of  the 
list  and  that  of  e2  are  same 

pass  <Ei's  head,  e2>  to  the  parent  with  a  new  t_occ 

if  right  event  e3  is  signaled 
flush  El's  buffer 

Figure  12  illustrates  the  detection  of  P  event,  P(F?i,  E2,  E3)  in  various  contexts. 

5.  P*:  P*  is  accumulative  variant  of  P.  P*  occurs  only  once  when  E3  occurs  and  accumulates 
the  time  of  occurrences  of  the  periodic  event  whenever  E2  occurs.  Unlike  P,  an  instance  of 
E2  cannot  be  either  an  initiator  or  a  terminator.  Only  an  Ei  occurrence  can  be  an  initiator 
and  an  E3  occiurrence  can  be  a  terminator.  In  the  implementation,  however,  an  occurrence  of 
E2  requests  the  temporal  event  handler  to  create  the  next  time  queue  item  without  defecting 
this  operator’s  semantics. 


P*iEi,  E2,  Ez): 


PROCEDURE  pstar_recent(Ei,  parameterJist)  /*  Recent  */ 

if  left  event  el  is  signaled 

get  the  terminator  ID  of  el 

create  a  time  queue  item  with  the  ID  and  the  time  string  of  E2 
replace  el  in  Ei's  list. 

if  middle  event  e2  is  signaled 
get  the  ID  of  e2 

if  El’s  list  is  not  empty  and  the  ID  of  el  and  that  of  e2  are  same 
create  a  time  queue  item  with  the  ID  and  the  time  string  of  E2 
append  e2  to  E2's  list 

if  right  event  e3  is  signaled 
if  El's  list  is  not  empty 
if  E2's  list  is  not  empty 

pass  <el,  all  e2s  in  E2's  list,  e3>  to  the  parent  with  a  new 
t_occ 

else 

pass  <el,  e3>  to  the  parent  with  a  new  t_occ 
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Figure  12:  Illustration  of  P(E1,  E2,  E3)  event  detection  in  various  contexts,  where  E2  is  a  time 
expression. 


flush  El  and  E2's  buffers 


Except  in  recent  context,  an  occurrence  of  Ei  stays  valid  until  its  matching  E3  occurs.  Until 
the  matching  E3  occurs,  a  time  queue  item  is  created  with  the  instance  number  of  the  Ei 
occurrence  every  time  interval  expressed  by  E^-  That  is,  it  is  like  having  a  separate  E2  list 
for  "each  occurrence  of  Ei. 


PROCEDURE  pstar_chronicle(Ei,  parameter-list)  /*  Chronicle  */ 

if  left  event  el  is  signaled 

get  the  terminator  ID  of  el 
if  Recent  context  is  not  set 

create  a  time  queue  item  with  the  ID  and  the  time  string  of  E2 
append  el  in  Ei's  list. 

if  middle  event  e2  is  signaled 
get  the  ID  of  e2 
if  El  list  is  not  empty 

if  the  ID  is  found  in  Ei's  list  and  if  Recent  context  is  not  set 
create  a  time  queue  item  with  the  ID  and  the  time  string 
of  E2 

append  e2  to  E2's  list 

if  right  event  e3  is  signaled 
if  El’s  list  is  not  empty 

if  E2’s  list  is  not  empty  ' 

pass  <.Bi’s  head,  all  e2s  in  list  whose  IDs  axe  the  same 
with  the  event  ID  of  the  Ei’s  head,  e3>  to  the  parent 
with  a  new  t-occ 
delete  the  head  of  Ei’s  list 

delete  all  e2s  in  E2’s  list  whose  t-occ  is  less  than  that 
of  El’s  new  head 
if  El’s  list  is  empty 
flush  E2’s  buffer 

else 

pass  <Ei’s  head,e3>  to  the  parent  with  a  new  t_occ 
delete  head  of  Ei’s  buffer 
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PROCEDURE  pstar_continuous(Ei,  parameterJist)  /*  Continuous  */ 


if  left  event  el  is  signaled 

get  the  terminatorJD  of  el 

if  Recent  or  Chronicle  contexts  are  not  set 

create  a  time  queue  item  with  the  ID  and  the  time  string  of  E2 
append  el  in  E\S  list. 

if  middle  event  e2  is  signaled 
if  El’s  list  is  not  empty 
get  the  terminator  ID  of  e2 
if  Recent  or  Chronicle  context  is  not  set 

create  a  time  queue  item  with  the  ID  and  the  time  string  of  E2 
append  e2  to  Ei's  list 

if  right  event  e3  is  signaled 
if  El’s  list  is  not  empty 
if  E2’s  list  is  not  empty 
for  each  el  in  Ei’s  list 

pass  <el,  all  e2’s  whose  t_occ  are  greater  than  that 

of  els,  e3> 

to  the  parent  with  a  new  t_occ 
flush  El’s  and  E2’s  buflfers. 

else 

for  each  el  in  Ei’s  list 

pass  <el,  e3>  to  the  parent  with  a  new  t_occ 
flush  El ’s  huffier 


PROCEDURE  pstar_cumulative(Ei,  parameterJist)  /*  Cumulative  */ 

if  left  event  el  is  signaled 

get  the  terminator  ID  of  el 

if  Recent,  Chronicle,  or  Continuous  context  is  not  set 

create  a  time  queue  item  with  the  ID  and  the  time  string  of  E2 
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append  el  to  Ei ’s  list 


if  middle  event  e2  is  signaled 
if  Eis  list  is  not  empty 

get  the  terminator  ID  of  e2 

if  Recent,  Chronicle,  or  Continuous  contexts  are  not  set 

create  a  time  queue  item  with  the  ID  and  the  time  string 
of  E2 

append  e2  to  f?2’s  list 

if  right  event  e3  is  signaled 
if  El’s  list  is  not  empty 
for  each  el  in  Ei’s  list 

link  <el  and  all  e2s  whose  IDs  are  the  same  as  that 
of  els  > 

pass  the  <el  and  e2  list,  e3>  with  a  new  t_occ 
flush  El’s  and  E2’s  bufiers 

Figme  13  illustrates  the  detection  of  P*  event,  P*{E\,  E2,  E3)  in  various  contexts. 
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6  SNOOP  Preprocessor 


In  this  section,  we  present  the  details  of  the  use  of  the  Snoop  preprocessor  and  the  output  it  pro¬ 
duces.  We  also  discuss  how  the  preprocessor  works  with  Open  OODB  preprocessor.  This  section 
provides  the  syntactical  aspects  of  the  Section  3.  The  Snoop  preprocessor  processes  all  application 
source  programs  given  by  the  user  before  executing  the  ppCC  (OpenOODB  pre-proessor).  The 
preprocessing  extracts  appropriate  events  and  rules  from  the  user-defined  event  and  rule  specifica¬ 
tions  expressed  in  Snoop  and  inserts  them  into  the  application  program.  And  the  postpreprocessing 
wraps  all  of  the  methods  in  the  user-defined  reactive  classes  with  notifications. 

6.1  Snoop  BNF 

The  grammar  for^noop  is  shown  below: 

E  ::=  begin-of  El  \  end-of  El  \  El 
El  ::=  El  AND®  E2  |  El  OR  E2  1  E2 
E2  :;=  E2  SEQ  E3  |  E3 
E3  Any(Value,  E4)  |  E5  |  Any(Value,  E5) 

E4  ::=  E4,  E5  |  E5 
E5  ::=  A(E1,E1,E1) 

I  A*iEl,El,El) 

I  P(El,[time  string], El) 

I  P(El,[time  string]:parameter,El) 

1  P*{El,[tiTnestring]  :  parameter,  El) 

I  [absolutetimestring] 

I  (El)  +  [relativeiimestring] 

I  Explicit  Events 

I  Database  Events 

I  L:(E1)  /*  Where  L  is  a  label  */ 

I  (El) 

Value  integer  \  oo 

Event  expressions  generated  by  the  BNF  [Mis91]  axe  left  associative.  Labels  are  used  for  expressing 
interest  in  a  sub-expression  and  their  presence  determines  the  parameter  attributes  computed 
for  that  expression.  A  label  acts  as  an  identification  for  the  subexpression  in  a  complex  event 
expression.  A  label  is  also  interpreted  as  the  event  type  for  the  sub-expression  with  which  it  is 
associated;  for  each  such  event  a  ‘time  of  occturence’  attribute  is  generated  as  a  parameter.  Without 
label  association  it  would  not  be  possible  to  distinguish  the  occurrence  of  an  event  corresponding 
to  a  sub-expression  and  to  access,  if  need  be,  the  time  of  its  occurrence  from  the  parameter  object. 

6.2  Event  and  Rule  Specification 

The  syntax  of  the  Snoop  event/rule  specification  is: 

event-spec  ::=  event  event-modifier  method jsignature 
I  event  event_name  =  event.exp 

event-modifier  ::=  event-name 

^operators,  OR,  AND,  SEQ  will  be  given  as  symbols,  which  are  |,'  ,  and  >>  by  a  user 
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I  begin  (  event_name  ) 

I  end  (  eventjiame  ) 

I  begin  (  event_name  )  &&  end  (  event_name  ) 
I  end  (  event-name  )  &&  begin  {  event-name  ) 


rulespec  ::=  rule  rule-name  (  event -name, 

condition-function,  action-function 
[,  \parameter-contexi[ , [coupling-mode] 

,  [priority] ,  [rule-trigger.mode]]  ) 

parameter-context  ::=  RECENT  |  CHRONICLE  |  CONTINUOUS 

1  CUMULATIVE 

coupling -mode::=  IMMEDIATE]  DEFERRED]  DETACHED 
priority:—  positive  integer 
rule-trigger-mode::=  NOW  ]  PREVIOUS 

Items  enclosed  by  square  brackets  ([  ])  are  optional.  Both  begin-method  (by  indicating  be¬ 
gin  ("euent-namej)  and  end-method  events  (by  indicating  end  (event-name))  are  supported.  By 
default,  the  end  of  a  method  is  taken  to  be  the  event.  A  composite  event  is  expressed  with  event-exp, 
and  a  primitive  event  is  specified  with  event-modifier  and  method-signature,  which  is  a  prototype 
of  a  method.  In  Sentinel  both  class-level  and  instance  -level  events  are  supported.  A  class-level 
event  can  be  specified  either  inside  of  the  class  definition  or  in  the  application  program  by  prefixing 
a  class  name  before  method  signature  as  “class-name: :method.signature”.  An  instance-level  event 
can  be  specified  only  in  the  application  program.  The  name  of  the  instance  and  the  name  of  the 
class  should  be  given  by  the  user.  The  instance  name  is  given  by  postfixing  after  the  name  of  the 
event  as  “event.name:instance.name”,  and  the  class  name  is  given  as  the  class-level  event  specified 
outside  of  the  class  definition  is.  Only  integer,  float,  long  integer,  character,  and  character  string 
are  supported  as  the  types  of  the  parameters  of  a  method.  Currently,  only  functions  are  used  for 
specifying  condition/action.  In  the  current  host  environment  (i.e.,  C-I-+),  methods  cannot  be  used 
for  condition/action  since  their  invocation  is  tied  to  an  object  which  is  not  known  at  compile  time. 
But  these  condition  and  action  functions  can  access  stored  objects  as  well  as  objects  in  the  main 
memory.  The  parameter  option  must  come  first;  other  can  take  any  place.  The  parameter  context 
of  the  event  which  a  rule  subscribes  should  be  placed  right  after  action-function  if  it  exists.  If 
several  rules  need  to  be  defined  on  the  same  event  in  different  parameter  contexts,  then  the  rule 
definition  has  to  be  duplicated  for  each  context.  Coupling  modes  refer  to  the  execution  points. 
Currently,  immediate  and  deferred  coupling  modes  are  supported.  We  use  priority  classes  for  spec¬ 
ifying  rule  priority.  An  arbitrary  number  of  priority  classes  can  be  defined  amd  totally  ordered. 
We  allow  rule  specification  at  class  definition  time  and  as  part  of  an  application.  We  also  support 
rule  activation  and  deactivation  at  run  time.  Moreover,  named  events  can  be  reused  later.  This 
implies  that  a  number  of  rules  may  be  defined  on  the  same  event  expression.  We  provide  an  option 
rule-trigger-mode  for  specifying  the  time  from  which  event  occurrences  are  to  be  considered  for  the 
rule.  Two  options,  NOW  (start  detecting  all  constituent  events  starting  from  this  time  instant)  and 
PREVIOUS  (all  constituent  events  are  acceptable)  are  supported  as  rule  triggering  modes,  with 
NOW  being  the  default.  To  declare  events  and  rules,  the  class  should  be  a  user-defined  reactive 
class.  Below,  examples  of  events  and  a  rule  specified  inside  of  the  class  definition  are  shown: 

class  STOCK:  public  REACTIVE  { 
public: 
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event  begin(el)  &&  end(e2)  void  set_price(float  price); 
event  end(e3)  int  sell^tock(int  qty); 
int  get_price(); 

event  e4  =  el  '  e3;  /*  AND  composite  event  */ 

rule  Rl(e4,  condl,  actionl,  CUMULATIVE,  DEFERRED,  10,  NOW);  /*  class-level  rule  */ 

}; 

The  following  examples  show  ,the  events  and  rules  specified  outside  of  the  class  definition,  where 
is  in  an  application  program  : 


STOCK  *IBM,  *DEC,  *INTEL; 

event  begin(e5:IBM)  &&  end(e6:DEC)  void  STOCK::set_price(float  price); 

/*  Instance(IBM  and  DEC)-level  event  */ 
event  end(e7)  int  STOCK::get_price();  /*  Class-level  event  */ 
event  e8  =  STOCK_e4  >>  e7;  /*  SEQ  composite  event  */ 

rule  Rl(STOCK_e3,  cond2,  action2,  DEFERRED,  20,  NOW);  /*  class-level  rule  */ 
rule  Rl(e5,  cond3,  action3,  CUMULATIVE,  IMMEDIATE,  15);  /*  instance-level  rule  */ 


To  access  the  events  specified  inside  of  the  class  definition  from  the  outside,  we  have  to  prefixing  the 
class  name  to  the  event  name  with  an  imderline  as  “classname.eventname” .  In  the  above  examples, 
STOCK_e3  and  STOCK_e4  show  the  prefixing. 

6.3  Preprocessing:  Event  and  Rule  Declarations 

The  preprocessing  declares  appropriate  events  and  rules  with  user-defined  event  and  rule  speci¬ 
fications  expressed  in  Snoop  and  inserts  them  in  the  application  program.  Here,  we  show  how 
these  events  and  rules  preprocessing  takes  place  and  how  the  non-Snoop  codes  rire  processed  with 
examples. 

6.3.1  Primitive  event 

•  Class-level  event  specified  in  a  reactive  class  definition  : 
class  STOCK:  public  REACTIVE 
{ 

event  begin{el)  int  buyjtock(int  number); 


} 

The  event  specification  in  the  above  example  is  transformed  as, 
PRIMITIVE  *STOCK_el  =  new  PRIMITrVE{“STOCK_el”,  “STOCK”, 

“begin”,  “int  buy^tock(int  number)”); 

•  Class-level  event  specified  not  in  a  reactive  class  definition  : _ 

event  hegin{e2)  Szk  end(e3)  void  STOCK::set_price(float  price); 

The  above  example  is  transformed  into  two  primitive  events  as, 
PRIMITIVE  *e2  =  new  PRIMITIVE (“e2”,  “STOCK”,  “begin”. 
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“void  set_price(float  price)”); 

PRIMITIVE *  *e3  =  new  PRIMITIVE( “e3” ,  “STOCK”,  “end”, 
“void  set_price(float  price)”); 


•  Instance-level  event  : 

An  instance-level  event  can  be  specified  only  outside  of  a  reactive  class  definition. 
STOCK  *IBM,  *DEC; 

'v 

event  end(e4:IBM)  int  STOCK::sell-stock(int  number); 

The  instancy  name  should  be  specified  as  well  as  the  class  name. 

It  is  transformed  as, 

PRIMITIVE  *e4  =  new  PRIMITIVE(“e4”,  IBM,  “end”, 

“int  sell^tock(int  number)”); 


6.3.2  Composite  event 

A  composite  event  is  specified  with  a  name  and  an  event  expression.  The  event  expression  specifies 
its  constituent  primitive  or  composite  events  using  the  Snoop  operators.  When  an  event  expression 
is  processed,  ral1.<;  for  creating  the  event  graph  for  that  event  expression  which  itself  composes  an 
event  tree  are  added  to  the  application  code.  The  examples  are  followed. 
event  e8  -  A*(  !(el,  e2,  e3),  e2,  A(e4,  e5,  (e6"  e7))); 

event  e9  =  (e3  |  el  )  "  e2  ; 

The  two  examples  are  transformed  each  as, 

A_star  *e8  =  new  A_star(  new  NOT(el,e2,e3),  e2,  new  A(e4,  e5,  new  AND(e6,e7))); 

AND  *STOCK-e9  =  new  AND(  new  OR(STOCK_e3,STOCK_el),  STOCK_e2); 

Note  that  in  the  second  example,  the  event  names  are  prefixed  with  the  class  name.  This  means 
that  the  example  is  specified  inside  of  the  class  definition. 

6.3.3  Temporal  event 

Both  absolute  and  temporal  events  are  mostly  used  as  constituent  events  of  composite  events.  They 
have  time  expressions  instead  of  method  signatures  and  event  modifiers.  The  time  expression  does 
not  have  anything  to  do  with  a  reactive  class.  Thus  ^TEMPORAL”  replaces  the  class  name,  and 
a  null  string  replaces  the  event  modifier. 

•  Relative  temporal  event: 

When  a  relative  time  expression  is  used  in  one  of  P,  P*,  and  PLUS  operators,  it  is  declared 
as  a  relative  temporal  event.  But  the  temporal  event  does  not  have  any  name,  thus,  a  name 

should  be  given. _ 

event  elO  =  P(el,  [1  hr],  e2); 

If  the  above  event  is  specified  in  the  reactive  class  named  STOCK,  it  is  transformed  as, 
PRIMITIVE  *STOCK_rell  =  new  PRIMITIVE(“STOCK_rell”,  “TEMPORAL”, 

“”,  “1  hr”); 

P  *STOCK_elO  =  new  P(STOCK_el,  STOCKjrell,  STOCK.e2); 

The  name  “rell”  is  given  by  the  preprocessor.  The  number  (here,  it  is  1)  starts  from  1  and 
increases  by  1  in  every  reactive  class.  If  the  above  example  is  specified  in  an  application 
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program,  then  it  is  converted  as, 

PRIMITIVE  *rell  =  new  PRIMITIVE(“reU”,  “TEMPORAL”, 

“1  hr”); 

P  *elO  =  new  P(el,  rell,  e2); 

The  number  in  the  name  “rell”  starts  from  1  at  the  beginning  of  the  application  program 
and  increases  by  1. 

•  Absolute  temporal  event  : _ 

event  hi  =  [14:25:00/04/23/96]; 

If  the  above  absolute  temporal  event  is  specified  in  a  reactive  class  definition,  where  the  class 
name  is  “STOCK” ,  it  is  converted  as, 

PRIMITIVE  *STOCK.ell  =  new  PRIMITIVE(“STOCK.e5”,  “TEMPORAL”, 

“”,  “14:25:00/04/23/96”); 

If  it  is  specified  outside  of  the  class  definition,  it  is  transformed  as, 

PRIMITIVE  *ell  =  new  PRIMITIVE(“e5”,  “TEMPORAL”,  “”, 

_ “14:25:00/04/23/96”); _ 

event  eU  =  P([00:00:00/01/01/96],  [7  days],  [00:00:00/12/31/96]); 

In  the  above  example,  two  absolute  temporal  events  are  specified  without  their  names.  The 
Snoop  preprocessor  give  them  names.  If  an  absolute  temporal  event  is  specified  outside  of  a 
class  definition,  an  integer  number  is  given  with  “abs”  string  as  “absl”  for  the  event.  If  it 
is  specified  in  a  reactive  class  definition,  the  class  name  is  prefixed  as  “STOCK_absl”.  The 
integer  starts  from  1  and  increases  by  1  in  every  reactive  class  definition.  The  above  example 
is  transformed  as, 

PRIMITIVE  *absl  =  new  PRIMITIVE(“absl”,  “TEMPORAL”, 

“”,  “00:00:00/01/01/96”); 

PRIMITIVE  *rell  =  new  PRIMITIVE{“rell”,  “TEMPORAL”, 

“”,  “7  days”); 

PRIMITIVE  *abs2  =  new  PRIMITIVE(“abs2”,  “TEMPORAL”, 

“”,  “00:00:00/12/31/96”); 

P  *el2  =  new  P(absl,  rell,  abs2); 
or 

PRIMITIVE  *STOCK^bsl  =  new  PRIMITIVE(“STOCK^bsl”,  “TEMPORAL”, 

“”,  “00:00:00/01/01/96”); 

PRIMITIVE  *STOCK_rell  =  new  PRIMITrVE(“STOCK_rell”,  “TEMPORAL”, 

“”,  “7days”); 

PRIMITIVE  *STOCK^bs2  =  new  PRIMITIVE(“STOCK_abs2”,  “TEMPORAL”, 

“”,  “00:00:00/12/31/96”); 

P  *STOCK_el2  =  new  P(STOCK^bsl,  STOCKjrell,  STOCK_abs2); 

6.3.4  Rule 

There  should  be  an  event,  a  condition,  and  an  action  to  specify  a  rule.  As  you  can  see  in  the  rule 
specification,  a  rule  can  have  at  most  four  options  for  detecting  the  event  which  it  subscribes  or  for 
triggering  the  rule  in  a  certain  mode.  Except  the  first  option  which  is  parameter-context^  they  can 

be  specified  in  any  order. _ 

I  rule  rl[el,  check-price,  set-price,  RECENT,  IMMEDIATE,  NOW,  10]; 

The  above  rule  specification  is  converted  as  the  following  if  it  is  a  class-level  rule  whose  class  is 
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STOCK: 

RULE  *rl  =  new  RULE(“rr’,  STOCK_el,  check_price,  set.price,  RECENT); 

rl->set_mode(IMMEDIATE); 

rl->set_parameter(NOW); 

rl->set_priority(10); 

6.3.5  Non-Snoop  codes 

The  non_Snoop  C-I-+  codes  are  passed  through  the  Snoop  preprocessing  without  any  modifications. 
The  preprocessor  also  inserts  Sentinel-related  codes  in  the  application  program  to  make  it  easy  for 
the  user  to  use  the  Sentinel  local  event  detector  without  worrying  about  details.  The  example 
application  program  and  its  after-Snoop-preprocessed  C+-1-  codes  can  be  found  in  section  6.7. 

6.4  Files  generated  by  the  Preprocessor 

The  preprocessor  produces  several  files  for  other  Sentinel  server  applications  such  as  the  rule  ex¬ 
ecution/visualization  tool  [Zho95]  and  rule  editor.^.  For  the  visualization,  events  and  rules  are 
reported  with  their  descriptions  and  their  class  names  For  rule  editor,  all  of  the  method  signatures 
of  reactive  classes  are  enumerated  in  a  file. 

6.5  Postprocessing  and  Integrating  into  Open  OODB  preprocessor 

Event  methods  that  can  generate  primitive  events  should  be  wrapped  with  notifications.  The 
Open  OODB  preprocessor  also  wraps  class  methods  for  its  sentry  mechanism.  The  Open  OODB 
preprocessor  renames  an  original  method  by  postfixing  it  with  a  string  ‘LOOdbFn”,  creates  a 
wrapper  method  which  has  the  original  method  name,  and  inserts  calls  into  the  wrapper  method. 
The  function  named  xwrapper.func.code  generates  OODB  code  for  the  wrapped  methods.  We 
modified  it  to  insert  notifications  if  the  method  is  one  of  a  reactive  class.  The  rule  editor  allows  the 
user  to  create  rules  in  run  time.  For  the  event  methods  which  will  be  created  and  subscribed  by 
these  rules,  the  notifications  are  inserted  to  all  of  the  methods  of  a  reactive  class  with  a  condition. 
The  condition  checks  to  see  if  there  are  any  rules  subscribing  the  method  at  that  time.  If  there  are, 
the  notifications  go  to  the  local  event  detector  before  and  after  the  invocation  of  the  original  user 
method.  Before  any  notification  of  the  method,  the  parameters  of  the  method  are  collected,  linked 
in  a  list  and  sent  with  the  notifications  to  the  event  detector.  An  example  of  a  v.Tapper  method 
after  the  Open  OODB  and  Snoop  postprocessing  can  be  found  in  section  6.7. 

6.6  Running  Snoop  Preprocessor 

The  Open  OODB  toolkit  drivers  calls  the  C-f-l-  preprocessor,  Open  OODB  preprocessor  and  then 
C-1-4-  compiler.  By  modifying  the  driver  to  call  the  Snoop  preprocessor  first,  using  the  Sentinel 
local  event  detector  becomes  easy  for  the  user.  The  Snoop  preprocessing  can  be  disabled  by  the 
s  option;  in  that  case,  the  user  only  calls  the  Open  OODB  preprocessor.  The  option  is  given  like 
those  of  the  Open  OODB  preprocessor  or  C++  compiler. 

6.7  Example  of  Snoop  Preprocessing 
Original  Program: 

is  under  development. 
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class  STOCK  :  public  REACTIVE 

{ 

private: 


public: 


event  end(el)  int  sell_stock(int  qty); 

event  hegin(e2)  &&  end(e3)  void  set-price(float  price); 

int  get_price(); 

event  e4  =  el  "  e2;  /*  AND  operator  */ 

/*  class-level  rules  */ 

rule  Rl[e4,  fiondl,  actionl,  CUMULATIVE,  DEFERRED]; 

}; 

int  STOCK:  :sell^tock(int  qty)  { .  } 

void  STOCK::set_price(float  price)  { .  } 

int  STOCK::get_price()  {  .  } 

/*  Main  program  */ 

STOCK  IBM,  DEC,  Microsoft; 
main() 

{ 


/*  Creating  instance-level  primitive  event  */ 

event  begin(instancejet_price:IBM)  void  STOCK::set_price(float  price); 
/*  SEQUENCE  operator  */ 

event  seq-event  =  STOCK_e4  >>  instance_set_price; 

/*  Creating  class-level  primitive  event  */ 

event  begin(sell-stock)  void  STOCK::selljstock(int  qty); 

/*  Creating  class-level  P  event  */ 

event  p.event  =  P([00:00:00/01/01/96],  [7  days],  [00:00:00/12/31/96]); 

/*  Creating  a  rule  which  contains  both  class-level 

and  instance-level  events  */ 

rule  R2[seq_event,  cond2,  action2,20,  PREVIOUS]; 

j*  Creating  a  class-level  rule  */ 

rule  R3[p_event,  cond3,  action3,  RECENT]; 


OpenOOBD->beginTransaction(); 

IBM.set_price(115.00); 

DEC.set_price(100.00); 

Microsoft.sell^tock(200); 

DEC.get_price(); 

IBM.set_price(75.95); 

OpenO  ODB-  >  commitTransaction  () ; 


Snoop  Preprocessed  Program: 


class  STOCK  :  public  REACTIVE 

{ 
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private: 


public: 


int  sell^tock(int  qty); 
void  set_price(float  price); 
int  get_price(); 

}; 

/*  Main  program  */ 

STOCK  IBM,  DEC,  Microsoft; 

LOCAL_EVENTJ)ETECTOR  *Event-detector; 

void  init_func();  \ 

main() 

{ 

/*  Creating  the  local  event  detector  */ 

Event-detector  =  new  LOCAL_EVENT_DETECTOR(); 
init_func(); 

/*  Creating  primitive  events  */ 

PRIMITIVE  *STOCK_el  =  new  PRIMITIVE(“STOCK_el”,  “STOCK” 

“end”,  “int  sell_stock(int  qty)”); 

PRIMITIVE  *STOCK-e2  =  new  PRIMITIVE(“STOCK_e2”  “STOCK”, 

“begin”,  “void  set_price(float  price)”); 
PRIMITIVE  *ST0CK.e3  =  new  PRIMITIVE(“STOCK.e3”,  “STOCK”, 

“end”,  “void  set-price  (float  price)”); 

/*Composite  event  AND  */ 

AND  *STOCK-e4  =  new  AND(STOCK-el,  STOCK_e2); 

/*  Creating  Rule  R1  */ 

RULE  *R1  =  new  RULE(“R1”,  STOCK-e4,  condl,  actionl,  CUMULATIVE); 
Rl->set-mode(DEFERRED) ; 

/*  Creating  instance-level  primitive  event  */ 

PRIMITIVE  *instance-set-price  =  new  PRIMITIVE(“instance-set-price”, 

IBM,  “begin”,  “void  set  price(float  price)”); 

/*  Composite  event  SEQUENCE  */ 

SEQ  *seq-event  =  new  SEQ(STOCK-e4,  instance-set .price); 

/*  Composite  event  P  */ 

PRIMITIVE  *absl  =  new  PRIMITIVE(“absl”,  “TEMPORAL”, 

“”,  “00:00:00/01/01/96”); 

PRIMITIVE  *rell  =  new  PRIMITIVE(“rell”,  “TEMPORAL”, 

“”,  “7  days”); 

PRIMITIVE  *abs2  =  new  PRIMITIVE(“abs2”,  “TEMPORAL”, 

“”,  “00:00:00/12/31/96”); 

P  *p-event  =  new  PSTAR(absl,  rell,  abs2); 

/*  Creating  Rule  R2  */ 

RULE  *R2  =  new  RULE(“R2”,  seq.event,  cond2,  action2); 

R2->set-priority(20); 

R2->set_triggerjnode(PREVIOUS); 
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/*  Creating  Rule  R2  */ 

RULE  *R3  =  new  RULE{“R3”,  p-event,  cond3,  action3,  RECENT); 
Notify  (NULL,  “OODB”,  “beginT”,  “begin”,  systemJist); 

OpenO  ODB-  >  beginTransact  ion  ( ) ; 

Notify(NULL,  “OODB”,  “beginT”,  “end”,  systemJist); 
IBM.set_price(115.00); 

,,  DEC.set-price(lOO.OO); 

Miprosoft.sell_stock(2O0) ; 

DEO.get-priceO; 

IBM.set_price(75.95); 

Notify(NULL,  “OODB”,  “commitT”,  “begin”,  systemJist); 
OpenOODB-^commit  0 ; 

Notify  (NULL,  “OODB”,  “commitT”,  “end”,  systemJist); 

} 

Open  OODB  Preprocessed  Program: 

class  STOCK  :  public  virtual  .Wrapper,  public  REACTIVE 

{ 

private: 


public: 


int  sell.stock_OOdbFn(int  qty); 
int  selljstock(int  —looAgrO); 
void  set_price_OOdbFn(float  price); 
void  set_price(float  _looAgrO); 
int  get_price_OOdbFn(); 
int  get_price(); 

}; 

int  STOCK::sell.stock_OOdbFn(int  qty) 

{ 

/*  original  sell.stock  method  */ 

} 

int  STOCK::sell.stock(int  _looArgO) 

{ 

....  Open  OODB  code  ... 

/*  Parameters  are  collected  in  a  linked  list  */ 
PARAJJST  *selljstockJist  =  new  PARAXIST(); 
selljstockJist->insert(“qty”,  INT,  ..looArgO); 
if  is_begin_of_this.subscribed_ 

/*  Notify  begin  of  method  */ 

Notify(this,  “STOCK”,  “int  sell.stock(int  qty)”, 
“begin”  ,sell.stock  Jist) ; 

/*  The  original  sell  stock  method  is  invoked  here  */ 
int  ret.value  =  sell.stock_OOddbFn(_looArgO); 

/*  Only  if  this  event  is  subscribed  */ 
if  is_end_of_thisjsubscribed 
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/*  Notify  end  of  method  */ 

Notify  (this,  “STOCK”,  “int  sell^tock(int  qty)”, 

“end”  ,sell_stock  Jist) ; 

return(ret_value) ; 

} 

void  STOCK: :set_price_OOdbFn(float  price) 

/*  original  set-price  method'*/ 

} 

void  STOCK::set_price(float  __looArgO) 

{ 

....  Open  OCMDB  code  ... 


/*  Parameters  are  collected  in  a  linked  list  */ 
PARAXIST  *set_priceJist  =  new  PARAXIST(); 
set_priceJist->insert(  “price” ,  FLOAT,_looArgO); 
if  is-begin_of_this_subscribed 
/*  Notify  begin  of  method  */ 

Notify(this,  “STOCK”,  “void  set_price(float  price)” 

“begin”  ,set_price  Jist) ; 

/*  The  original  set  price  method  is  invoked  here  */ 
set.price_OOdbFn(_looArgO) ; 
if  is_end_of_this^ubscribed 
/*  Notify  end  of  method  */ 

Notify(this,  “STOCK”,  “void  set-price(float  price)” 

“end”,  set-priceJist); 


int  STOCK::get-price-OOdbFn(char  *nl) 

{ 

/*  original  get-price  method  */ 

} 

int  STOCK::get_price(char  _looArgO) 

{ 

....  Open  OODB  code  ... 

/*  Parameters  are  collected  in  a  linked  list  */ 
PARAXIST  *get_priceJist  =  new  PARAXIST(); 
get_priceJist->insert(“nl”,  char,  _looArgO); 
if  is_begin_of_thisjsubscribed 
/*  Notify  begin  of  method  */ 

Notify(this,  “STOCK”,  “void  get_price(char  *nl)”, 

“begin”  ,get_price  Jist) ; 

/*  The  original  set  price  method  is  invoked  here  */ 
int  ret-value  =  get_price_OOdbFn(_looArgO); 
if  is_end_of_this_subscribed 
/*  Notify  end  of  method  */ 

Notify(this,  “STOCK”,  “void  get_price(char  *nl)”, 

“end”,  get-priceJist); 
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return(ret_value);  ]]  } 

This  example  illustrates  the  use  of  class-level  and  instance-level  events  and  rules  and  also  shows 
the  wrapping  of  the  methods  with  a  collection  of  parameters,  which  are  done  by  the  Open  OODB 
preprocessor.  A  class-level  composite  event  e4  is  defined  which  is  an  AND  of  el  and  e2.  A  class- 
level  rule  R1  is  defined  on  event  e4.  Instance-level  primitive  event  setJBMjprice  is  defined  for 
STOCK  object  IBM.  A  composite  sequence  event  is  defined  which  is  a  combination  of  an  instance- 
level  and  class-level  event  and  finally  rule  R2  is  defined  on  the  sequence  event  (seq.event).  A 
periodic  event.  p_ei;ent  is  defined  with  absolute  time  interval.  R3  subscribes  p_event.  Notice 
that  after  preprocessing  the  user-defined  methods  ‘sell^tock’,  ‘set.price’,  and  ‘get.price’  are  re¬ 
named  as  ‘sell_stock_OOdbFn’,  ‘set.price.OOdbFn’  and  ‘get_price_OOdbFn’,  and  wrapper  methods 
‘selljstock’,‘set_pi^ce’  and  ‘get.price’  are  introduced.  Currently  ‘get.price’  is  not  subscribed  by  any 
of  event  of  rule,  but  the  reason  why  it  is  also  wrapped  is  that  we  allow  the  user  to  create  the  rules 
subscribing  the  event  later  through  the  rule  editor.  As  seen  from  the  example,  appropriate  code  is 
introduced  in  the  wrapper  methods  to  notify  the  events.  Also  the  processing  of  the  application  - 
level  rule  and  event  specification  procues  appropriate  code  for  generation  of  event  and  rule  objects 
along  with  the  relevant  parameters. 

Regarding  the  detection  of  events  Rule  R2  will  be  fired  first  because  it  is  in  immediate  mode 
with  parameters  {{DEC,  price,  FLOAT,  100.00},  {Microsoft,  qty,  INT,  200},  {IBM,  price,  FLOAT, 
75.95}}.  Rule  R1  will  be  fired  later  since  it  is  in  deferred  mode  with  parameters  {{IBM,  price, 
FLOAT,  115.00},  {DEC,  price,  FLOAT,  100.00},  {Microsoft,  qty,  INT,  200}}.  Both  DEC  and 
IBM  prices  will  be  parameters  to  Rule  R1  since  its  context  is  specified  to  be  CUMULATIVE.  Rule 
R3  is  fired  every  seven  days  between  “00:00:00/01/01/96”  and  “00:00:00/12/31/96”. 
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7  Conclusions 


This  report  extends  earlier  work  on  local  event  detection  in  Sentinel.  The  local  event  detector 
was  extended  to  support  temporal  events  according  to  the  semantics.  We  integrated  the  local  event 
detector  with  the  stand-alone  temporal  event  handler  first  to  support  other  Snoop  operators.  For 
the  integration,  the  implementation  of  the  local  event  detector  and  the  temporal  event  handler 
were  modified.  In  the  local  event  detector,  the  implementation  of  primitive  events  was  modified  to 
generate  temporal  items  which  are  handled  by  the  temporal  event  handler  since  a  temporal  event 
is  a  primitive  event.  The  Snoop  operators,  A  and  A*,  are  reimplemented  with  new  parameter 
computation  algorithms.  P  and  P*  are  implemented  to  have  time  capabilities  with  their  new  event 
detection  algorithms.  PLUS  is  implemented  for  supporting  relative  temporal  events.  In  addition, 
the  stand-alone  tejpporal  event  handler  has  been  changed  to  integrate  with  the  local  event  detector 
to  meet  the  new  complicate  situations  which  were  not  found  when  it  was  implemented  originally. 

The  earlier  work  assumed  that  Snoop  event /rule  specifications  were  transformed  to  internal 
event /rule  declarations,  and  the  specified  event  methods  were  wrapped  with  notifications  to  the 
local  event  detector.  We  implemented  the  Snoop  preprocessor  so  that  the  event/rule  specifications 
are  transformed  to  the  internal  forms. 

We  removed  the  Snoop  postpreprocessor  and  modified  the  Open  OODB  preprocessor  to  wrap 
the  methods  of  a  reactive  class.  Every  method  of  a  reactive  class  is  wrapped  by  notifications  with 
condition  statements  which  check  the  method  is  bound  to  an  event  at  run  time.  This  extended 
wrapping  allows  extra  rule  editing  at  run  time.  The  preprocessor  produces  a  few  side  files  for  other 
Sentinel  applications  such  as  global  rule  editor  and  rule  debugger. 

This  report  also  explained  the  local  event  detector  and  the  temporal  event  handler.  Construct¬ 
ing  of  an  event  graph,  detecting  of  both  primitive  and  composite  events,  and  handling  of  temporal 
events  were  described. 
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